asp.net - POST请求的GENERAL_REQUEST_ENTITY期间发生错误，导致ASP .NET session 状态永不解锁

Question

(来自Server Fault的交叉发布，那里没有任何吸引力):
我一直试图找出导致Web请求由于意外错误而终止后ASP .NET session 状态保持锁定的情况的根本原因。我们使用SQL Server session 状态提供程序进行 session ，因为我们在Web场中有多个服务器。此问题首先以许多请求的形式出现，它们毫无明显的原因卡在其生命周期的“AcquireRequestState”事件中。我能够在SQL Server的 session 状态数据库中为所有这些锁定(列Locked = 1)的请求找到相应的条目。我还能够将这些请求与HTTP状态代码为500(子状态为0)的IIS日志中的条目相关联。这些发现使我相信，在某些情况下，请求出错了，但并没有像应有的那样释放对 session 状态的锁定。

我为有问题的网站的状态代码500启用了IIS中的“失败请求跟踪”功能，所有可用的提供程序都被选中，每个提供程序的详细程度都设置为“详细”。从那以后，我收集了一些失败的跟踪，这些跟踪已导致永久锁定ASP .NET session 。它们都具有相同的特征:

它们都是浏览器正在发布要处理/保存的数据的“POST”请求。

它们都具有指示在REQUEST_ACQUIRE_STATE事件期间调用了“ session ”模块的事件。此时，该请求会将 session 状态数据库中的行标记为“已锁定”。这是正常现象，是预期的。

它们都具有GENERAL_READ_ENTITY_START，GENERAL_READ_ENTITY_END和GENERAL_REQUEST_ENTITY条目，这些条目似乎正在读取作为请求一部分发送到服务器的数据。这似乎是一项缓冲操作，因为这些事件一遍又一遍地重复，每次读取已发布数据的某些子集时都会重复。

在“读取实体”相关事件中的某个时刻发生错误。一些错误代码为“功能不正确。(0x80070001)”，另一些错误代码为“由于线程退出或应用程序请求(0x800703e3)，I / O操作已中止。”

一旦遇到错误，它们都会直接跳到END_REQUEST事件。

这里的问题是，在正常情况下，应该有一个RELEASE_REQUEST_STATE事件，该事件将允许Session模块释放其对 session 的锁定。在这种情况下，将跳过此事件。可以肯定的是，我也为'200'状态代码启用了失败的请求跟踪，并生成了一些成功请求的跟踪，这些跟踪确实由Session模块处理了RELEASE_REQUEST_STATE事件。

一位同事指出，您还可以通过调用HttpContext.Current.ApplicationInstance.CompleteRequest()来使请求直接跳到“END_REQUEST”事件。我对此进行了测试，发现在发布请求期间使用此方法创建的跟踪与发生此问题时所捕获的跟踪非常相似，但仍可以正确清理 session 。这导致我在存储 session 的SQL Server数据库上运行SQL Profiler，以跟踪对存储过程的所有调用。当由于调用CompleteRequest()而直接跳到END_REQUEST时，将按预期进行调用以更新 session 状态(并释放锁)。当由于GENERAL_REQUEST_ENTITY期间的错误而跳至END_REQUEST时，永远不会进行更新或释放 session 状态锁定的调用。

我的理论是，某种网络问题导致“错误的功能”和“由于线程退出或应用程序请求而导致的I / O操作被中止”错误，但是我不明白为什么这似乎导致请求处理跳过了释放 session 锁定状态。如果请求通过REQUEST_ACQUIRE_STATE，似乎它也应该在请求结束时的某个时候释放锁。我不愿意说这是IIS或ASP .NET中的错误，但在目前看来，这种方式对我来说似乎是正确的。

是否有已知条件导致错误导致 session 状态锁无法释放？

Answer 1

事实证明，这与以下问题有关:ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress

在该问题的公认答案中指定的解决方法确实有效，但是Microsoft还发布了一个修补程序(在撰写本文时尚未公开)，该修补程序修补了 session 处理逻辑，从而避免了所有问题。