Question

这是我的环境： Win 7上的IIS7.5，.NET 4，应用程序池集成

的web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
</configuration>

Test.aspx文件

<%@ Page Language="C#" %>

<!DOCTYPE html>
<script runat="server">
    protected void OnAction(object sender, EventArgs e)
    {
        int count;
        status.Text = (int.TryParse(status.Text, out count) ? count + 1 : 0).ToString();

        Session["test"] = count;
    }
</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>IIS Session Hang Test</title>
    <script>
        var mutiPostback = function () {
            var e = document.getElementById('LinkButton1');
            e.click();
            e.click();
        };
    </script>
</head>
<body>
    <form id="Form1" method="post" runat="server">
        <asp:ScriptManager runat="server" ID="SM">
        </asp:ScriptManager>
        <asp:UpdatePanel ID="UpdatePanel1" runat="server">
            <Triggers>
                <asp:AsyncPostBackTrigger ControlID="LinkButton1"/>
            </Triggers>
            <ContentTemplate>
                <asp:Label runat="server" ID="status" />
            </ContentTemplate>
        </asp:UpdatePanel>
        <input type="button" id="button1" onclick="mutiPostback();" value="MultiPostback"/>
        <div style="display: none">
            <asp:Button ID="LinkButton1" runat="server" OnClick="OnAction" Text="Click" />
        </div>
    </form>
</body>
</html>

是的，多次回发是故意的，我们注意到这种行为会导致许多请求卡在RequestAcquireState中，并最终阻止服务器接受任何新请求。但是，此问题仅在IE下可见，而不在Chrome或FF上。

要测试，请连续单击多个回发按钮。这将更新状态编号。然后，当使用IE时，您将能够观察到该数字停止增加，表明请求卡住了问题。

我能够通过以下IIS和IE版本产生此问题：

IIS版本测试

7.5.7600.16385
7.5.7600.16385

IE版测试

9.0.8112.16421
Windows Server 2008 R2上的8.0.7600.16385
6.0.3790.3959在Windows Server 2003 SP2上

我观察到的异常是，当访问本地IIS时，Windows Server 2008 R2上的8.0.7600.16385不会导致此阻塞问题。但是，如果我使用浏览器访问远程IIS，则可以重现该问题。在IE 9上，无论IIS是远程还是本地，我都可以重现该问题。

以下是工作流程请求列表中被吊死请求的外观的屏幕截图。

Stuck Requests 现在我们已经找到了解决这个问题的几种方法，但在我们的情况下没有一种方法可以接受：

删除/注释掉会话使用情况。
将应用程序池更改为经典模式。

注意：我们还发现，即使我们不直接使用Session，如示例所示，问题仍然存在。 IE：如果我们添加一个Global.asax.cs并添加一个空的Session_Start事件处理程序，该请求仍将在RequestAcquireState中挂起。

有没有人知道为什么会发生这种情况？我们如何解决这个似乎只在集成管理管道模式下发生的问题？

Answer 1

从您的描述中，当它尝试获取您的请求的会话对象时，它看起来像IIS死锁。我不会在浏览器中寻找原因，因为这只能是服务器端问题。也许你做不了多少。如果它是一个死锁，那么它就是一个多线程，时序相关的问题。因此，如果不同的浏览器发送时间略有不同的请求，您会得到不同的结果此外，如果您在本地或远程运行浏览器，您的时间会略有不同。清空会话无济于事，因为问题出在会话获取上。完全禁用会话确实有帮助，因为根本不会获取会话。将AppPool更改为Classic会有所帮助，因为它具有不同的会话管理实现，并且没有死锁。要测试该假设，您可以尝试在客户端的回发之间插入一个人工延迟。这将产生不同的时间条件，并应该影响问题。

我必须说这些只是基于您的描述和我对IIS的经验的推测。我建议您将AppPool更改为Classic，因为性能下降不是那么大。

Answer 2

我的网站上有类似的问题。在我的情况下，我有一个页面，其中包含许多网格，每个网格都调用一个asmx webservice来检索他们的数据。如果用户在所有Web请求完成之前导航离开页面，则该用户的会话可能变得非常慢（加载页面至少几分钟），但其他用户的会话将不会受到缓慢的影响。对我来说，当我在服务器上安装.NET 4.5时，问题就开始了。

我在这里找到了一个页面：http://forums.asp.net/t/1888889.aspx/1?Question+regarding+a+possible+bug+within+NET+4+5说明这是.NET 4.5的一个已知问题。如果站点使用集成模式并且浏览器在等待使用ASP.NET会话的页面时断开连接，则可以触发该错误。（有关详细信息，请参阅帖子）。

我相信你的双回发案例可能会导致浏览器放弃其中一个请求，所以看起来这样会适用。此外，我和其他人已经注意到这个bug在使用IE时似乎更常见（尽管这只是巧合 - 它不是IE漏洞）

该帖子还介绍了一种解决方法（调整web.config中的uploadReadAheadSize设置），该解决方法为我解决了这个问题。

Answer 3

好消息！安装.Net 4.5.1

后，似乎已解决会话阻止问题

我已经将安装了.Net 4.5的Windows Server 2008 R2上的测试机器7.5.7600.16385升级到4.5.1，问题就消失了！

Answer 4

请注意，这与Stackoverflow帖子相同 - ＆gt; ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress

这似乎是ASP.NET 4.5中的回归。 ASP.NET团队正在开发一个补丁，但有一个临时的解决方法（参见上面提到的帖子）。

如果您不能等待公开广泛更新，则可以与Microsoft客户支持部门联系以获取修补程序请求。只需遵循打开支持案例的常规流程即可。例如，在线提交https://support.microsoft.com/oas/default.aspx?&gprid=548&&st=1&wfxredirect=1&sd=gn或致电支持http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone。您可能需要预先支付最低金额，但您可能会根据客户支持政策获得退款。只需要求客户支持专业人员联系Microsoft dot com的netfx45compat即可快速了解此问题。

由于 Varun Gupta（.NET Framework兼容性）

当访问会话时，IE双回发会在集成管理管道模式下挂起IIS 7

4 个答案: