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

Blu*_*Fox 20 internet-explorer iis-7 session-state integrated-pipeline-mode

这是我的环境:Win 7上的IIS7.5,.NET 4,App Pool Integrated

web.config中

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
</configuration>
Run Code Online (Sandbox Code Playgroud)

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>
Run Code Online (Sandbox Code Playgroud)

是的,多次回发是故意的,我们注意到这种行为会导致许多请求卡在RequestAcquireState中,并最终阻止服务器接受任何新请求.但是,这个问题只能在IE下观察,而不能在Chrome或FF上观察到.

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

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

IIS版本已经过测试

  1. 安装了.Net 4.5的Windows Server 2008 R2上的7.5.7600.16385
  2. 安装了.Net 4.5的Windows 7 Pro上的7.5.7600.16385

IE版测试

  1. Windows 7 Pro上的9.0.8112.16421
  2. Windows Server 2008 R2上的8.0.7600.16385
  3. Windows Server 2003 SP2上的6.0.3790.3959

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

这是一个屏幕截图,显示了挂起的请求在工作进程的请求列表中的样子.

被困的请求 现在我们已经找到了解决这个问题的几种方法,但在我们的情况下没有一个是可以接受的:

  1. 删除/注释掉会话使用情况.
  2. 将应用池更改为经典模式.

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

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

Alo*_*atz 8

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

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


Wes*_*ith 5

我的网站上有类似的问题.在我的情况下,我有一个页面,其中包含许多网格,每个网格都调用一个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的bug)

该帖子还描述了一种解决方法(调整web.config中的uploadReadAheadSize设置),该解决方法为我解决了问题.


Blu*_*Fox 4

好消息!安装.Net 4.5.1后,会话阻塞问题似乎已得到解决

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