Wir verwenden einen Out-of-Process-Sitzungsanbieter ScaleOut) für eine ASP.NET-Anwendung und wir haben festgestellt, dasswan ein Objekt, das nicht richtig für die Deserialisierung eingerichtet ist, gelangt versehentlich in die Sitzung.ewirken Sie immer, dass der gesamte Prozess beendet wird.

ei der Neuproduktion und Handhabung dieses Szenarios wird es noch interessante

Die Ausnahme, die den Prozess beendet, wird in @ ausgelös AnyStaObjectsInSessionState dessen Implementierung ziemlich einfach ist:

internal static bool AnyStaObjectsInSessionState(HttpSessionState session)
{
    if (session != null)
    {
        int count = session.Count;
        for (int i = 0; i < count; i++)
        {
            object obj2 = session[i];
            if (((obj2 != null) && (obj2.GetType().FullName == "System.__ComObject"))
                && (UnsafeNativeMethods.AspCompatIsApartmentComponent(obj2) != 0))
            {
                return true;
            }
        }
    }
    return false;
}

Hier ist der Stack-Trace, der zeigt, wie Ausnahmen hier den Prozess beenden:

An unhandled exception occurred and the process was terminated.

Application ID: /LM/W3SVC/1/ROOT

Process ID: 4208

Exception: System.Runtime.Serialization.SerializationException

Message: The constructor to deserialize an object of type 'Lucene.Net.QueryParsers.ParseException' was not found.

StackTrace:    at System.Runtime.Serialization.ObjectManager.CompleteISerializableObject(Object obj, SerializationInfo info, StreamingContext context)
   at System.Runtime.Serialization.ObjectManager.FixupSpecialObject(ObjectHolder holder)
   at System.Runtime.Serialization.ObjectManager.DoFixups()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Web.Util.AltSerialization.ReadValueFromStream(BinaryReader reader)
   at System.Web.SessionState.SessionStateItemCollection.ReadValueFromStreamWithAssert()
   at System.Web.SessionState.SessionStateItemCollection.DeserializeItem(String name, Boolean check)
   at System.Web.SessionState.SessionStateItemCollection.DeserializeItem(Int32 index)
   at System.Web.SessionState.SessionStateItemCollection.get_Item(Int32 index)
   at System.Web.SessionState.HttpSessionStateContainer.get_Item(Int32 index)
   at System.Web.Util.AspCompatApplicationStep.AnyStaObjectsInSessionState(HttpSessionState session)
   at System.Web.HttpApplicationFactory.FireSessionOnEnd(HttpSessionState session, Object eventSource, EventArgs eventArgs)
   at System.Web.SessionState.SessionOnEndTargetWorkItem.RaiseOnEndCallback()
   at System.Web.Util.WorkItem.CallCallbackWithAssert(WorkItemCallback callback)
   at System.Threading.ExecutionContext.runTryCode(Object userData)
   at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

InnerException: System.Runtime.Serialization.SerializationException

Message: The constructor to deserialize an object of type 'Lucene.Net.QueryParsers.ParseException' was not found.

StackTrace:    at System.Runtime.Serialization.ObjectManager.GetConstructor(Type t, Type[] ctorParams)
   at System.Runtime.Serialization.ObjectManager.CompleteISerializableObject(Object obj, SerializationInfo info, StreamingContext context)

Wir möchten zwei Dinge verstehen:

Wann macht FireSessionOnEnd fire für einen Out-of-Process-Anbieter und, was noch wichtiger ist, wie können wir dies in einer Entwicklungsumgebung nachahmen, die nicht unter Last steht? Ich habe mit reduzierten Sitzungs-Timeouts (auf eine Minute festgelegt), manuellem Aufrufen von Abandon () und manuellem Aufrufen von GC.Collect () experimentiert, alles ohne Erfolg.

Können wir Fehler, die in diesem Schritt auftreten, abfangen, um den App-Pool zu schützen? Die hier aufgeführten Ausnahmen werden mit @ protokollier Source = ASP.NET 2.0.50727.0 und erreichen die Anwendungsfehlerbehandlungsroutinen in global.asax nicht. Was können wir tun, um dieses Szenario zu verhindern, selbst nachdem entsprechende Checks & Balances auf sitzungsgebundene Objekte angewendet wurden?

Alle Einblicke wäre dankbar.