如何保护会话的序列号异常的应用程序池？ [英] How to protect application pools from session serialization exceptions?
问题描述
我们正在使用ASP.NET应用程序一个彻头彻尾的进程外会话提供商（ ScaleOut ），我们已经注意到，在的一个对象，正确不设置为反序列化在不经意间使得其进入会议将最终导致整个进程终止。
再现和处理这种情况是它会变得更加有趣。
终止过程中的异常中提出的 AnyStaObjectsInSessionState 的实施是pretty简单：
内部静态布尔AnyStaObjectsInSessionState（HttpSessionState会话）
{
如果（会话！= NULL）
{
诠释计数= session.Count;
的for（int i = 0; I＆LT;计数;我++）
{
反对OBJ2 =会话[I]
如果（（（OBJ2 =空）及！＆放大器;（obj2.GetType（）全名==系统.__ ComObject））
＆功放;＆安培; （UnsafeNativeMethods.AspCompatIsApartmentComponent（OBJ2）！= 0））
{
返回true;
}
}
}
返回false;
}
这里的堆栈跟踪显示异常这里是如何终止进程：
发生未处理的异常，过程被终止。应用程序ID：/ LM / W3SVC / 1 / ROOT进程ID：4208异常：System.Runtime.Serialization.SerializationException消息：构造反序列化类型'Lucene.Net.QueryParsers.ParseException的对象没有被发现。堆栈跟踪：在System.Runtime.Serialization.ObjectManager.CompleteISerializableObject（obj对象，SerializationInfo中的信息，的StreamingContext上下文）
在System.Runtime.Serialization.ObjectManager.FixupSpecialObject（持有的ObjectHolder）
在System.Runtime.Serialization.ObjectManager.DoFixups（）
在System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize（HeaderHandler处理器，__BinaryParser serParser，布尔FCHECK，布尔isCrossAppDomain，IMethodCallMessage methodCallMessage）
在System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize（流serializationStream，HeaderHandler处理器，布尔FCHECK，布尔isCrossAppDomain，IMethodCallMessage methodCallMessage）
在System.Web.Util.AltSerialization.ReadValueFromStream（BinaryReader读卡器）
在System.Web.SessionState.SessionStateItemCollection.ReadValueFromStreamWithAssert（）
在System.Web.SessionState.SessionStateItemCollection.DeserializeItem（字符串名称，布尔检查）
在System.Web.SessionState.SessionStateItemCollection.DeserializeItem（的Int32指数）
在System.Web.SessionState.SessionStateItemCollection.get_Item（的Int32指数）
在System.Web.SessionState.HttpSessionStateContainer.get_Item（的Int32指数）
在System.Web.Util.AspCompatApplicationStep.AnyStaObjectsInSessionState（HttpSessionState会话）
在System.Web.HttpApplicationFactory.FireSessionOnEnd（HttpSessionState会议，对象的EventSource，EventArgs的EventArgs的）
在System.Web.SessionState.SessionOnEndTargetWorkItem.RaiseOnEndCallback（）
在System.Web.Util.WorkItem.CallCallbackWithAssert（WorkItemCallback回调）
在System.Threading.ExecutionContext.runTry code（用户数据对象）
在System.Runtime.CompilerServices.RuntimeHelpers.Execute codeWithGuaranteedCleanup（试行code code，清理code撤销code，对象用户数据）
在System.Threading.ExecutionContext.Run（ExecutionContext中的ExecutionContext，ContextCallback回调，对象状态）
在System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal（_ThreadPoolWaitCallback tpWaitCallBack）
在System.Threading._ThreadPoolWaitCallback.PerformWaitCallback（对象状态）的InnerException：System.Runtime.Serialization.SerializationException消息：构造反序列化类型'Lucene.Net.QueryParsers.ParseException的对象没有被发现。堆栈跟踪：在System.Runtime.Serialization.ObjectManager.GetConstructor（T型，A型[] ctorParams）
在System.Runtime.Serialization.ObjectManager.CompleteISerializableObject（obj对象，SerializationInfo中的信息，的StreamingContext上下文）
我们想明白了两件事：
-
在做的 FireSessionOnEnd 火过程外的一个供应商，更重要的是，我们如何能模仿这种在开发环境负载下不？我已经尝试了降低会话超时（设置为一分钟），手动调用放弃（），并手动调用GC.Collect的（），一切都是徒劳。
-
可以在发生在这个步骤来保护应用程序池，我们捕获错误？这里提出的异常记录瓦特/ 源= ASP.NET 2.0.50727.0 并在Global.asax中没有达到应用程序错误处理程序。我们可以做些什么来防止这种情况下，即使经过适当的检查和放什么;余额用于会话绑定对象？
任何见解将是AP preciated。
我们能够解决这一问题的SOSS技术支持帮助 - 他们是有益的极大 - 在这里是详细内容：
- 当会话到期，SOSS引发期满事件在其客户端库，而这又是负责在Global.asax中（触发Session_End中的注：跨客户端ScaleOut负载平衡失效事件，所以网络创建该会议可能不会necesarily收到过期事件服务器 - 这是试图重现这些问题的）关键。
- 因为出现这种情况的请求的上下文之外，异常是未处理并杀死应用程序池;
- 这是一个非常罕见的情况只有一个，他们仍然会在即将到来的维护版本解决;
-
的补救措施如下：
-
修复的System.Exception 来源的类型（这是序列化，但不是不可序列化）;
-
删除Session_End中
在Global.asax中的事件或禁用
过期事件（ max_event_retries
设置为0 soss_params.txt）; -
在这些情况下，很可能是
用户遇到
SerializationException 上的一个
他们的请求，这意味着它达到
的Application_Error ;在这里你可以清除
会话密钥（必须清除所有的
它们）或放弃会话
彻底; -
订阅
AppDomain.UnhandledException 是
未处理的异常的通知，
他们应该发生（无追索权在这里，
只是记录）;它们也可以是
通过禁用
legacyUnhandledExceptionPolicy （不
推荐）;
-
We're using an Out-of-Process Session Provider (ScaleOut) for an ASP.NET application and we've noticed that when an object that's not correctly setup for de-serialization inadvertently makes its way into session it will eventually cause the entire process to terminate.
Reproducing and handling this scenario is where it gets even more interesting.
The exception that terminates the process is raised in AnyStaObjectsInSessionState whose implementation is pretty straightforward:
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;
}
Here's the stack trace that shows how exceptions here terminate the process:
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)
We would like to understand two things:
When does FireSessionOnEnd fire for an out-of-process provider and, more importantly, how can we mimic this in a development environment that's not under load? I've experimented with lowered session timeouts (set to a minute), manually invoking Abandon(), and manually invoking GC.Collect(), all to no avail.
Can we trap errors that happen at this step to protect the app pool? The exceptions raised here are logged w/ Source=ASP.NET 2.0.50727.0 and don't reach the application error handlers in global.asax. What can we do to guard against this scenario, even after appropriate checks & balances are applied to session-bound objects?
Any insights would be appreciated.
We were able to resolve this issue with the help of SOSS technical support – they were tremendously helpful – here are the details:
- Upon session expiry, SOSS raises an expiration event in its client libraries, which in turn are responsible for firing Session_End in Global.asax (N.B: ScaleOut load balances expiration events across clients, so the web server that created the session may not necesarily receive its expiration event - this is critical for trying to reproduce these issues).
- Because this happens outside the context of a request, the exception is unhandled and kills the app pool;
- It’s an extremely uncommon scenario but one that they will nonetheless address in upcoming maintenance releases;
The remedies are as follows:
Fix the System.Exception-derived type (that’s serializable but not unserializable);
Remove Session_End events in Global.asax or disable the expiration events (max_event_retries set to 0 in soss_params.txt);
In these scenarios, it’s likely that the user encounters a SerializationException on one of their requests, meaning it reaches Application_Error; here you can clear the session keys (must clear all of them) or abandon the session outright;
Subscribe to AppDomain.UnhandledException to be notified of unhandled exceptions, should they occur (no recourse here, just logging); they can also be disabled via legacyUnhandledExceptionPolicy (not recommended);
这篇关于如何保护会话的序列号异常的应用程序池？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
