IE double postback hangs IIS 7 in Integrated Managed pipeline mode when session is accessed

StackOverflow https://stackoverflow.com/questions/14963635

سؤال

Here's my environment: IIS7.5 on Win 7, .NET 4, App Pool Integrated

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>

Yes, the multiple postback is intentional, we notice this behavior will cause many request stuck in RequestAcquireState and ultimately prevent any new requests being accepted by the server. However, this problem is only observable under IE and not on Chrome or FF.

To test, continuously clicking the multiple postback button. This will update the status number. You'll then be able to observe that number stop increasing when using IE, indicating the request stuck issue.

I was able to produce this issue with following IIS and IE versions:

IIS versions tested

  1. 7.5.7600.16385 on Windows Server 2008 R2 with .Net 4.5 Installed
  2. 7.5.7600.16385 on Windows 7 Pro with .Net 4.5 Installed

IE version tested

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

An anomaly I observed, is that when accessing local IIS, 8.0.7600.16385 on Windows Server 2008 R2 does NOT cause this blocking issue. But if I use the browser to access a remote IIS, then the issue can be reproduced. While on IE 9 I can reproduce the issue regardless if IIS is on remote or local.

Here's a screen shot of how the hanged request look like in request list for worker process.

Stuck Requests Now we have found a few ways to get around this problem, but none are acceptable in our situation:

  1. Remove/Comment out Session usage.
  2. Change app pool to Classic mode.

NOTE: we also found that even if we don't directly use Session as shown in the example, the problem still occurs. IE: if we add a Global.asax.cs and add an empty Session_Start event handler, the request will still hang in RequestAcquireState.

Does anyone have a clue why this is happening and how can we resolve this issue that only seem to happen in Integrated managed pipeline mode?

هل كانت مفيدة؟

المحلول 3

Good news! It appears that the session blocking issue has been resolved after installing .Net 4.5.1

I've upgraded my testing machine 7.5.7600.16385 on Windows Server 2008 R2 with .Net 4.5 installed to 4.5.1 and the issue went away!

نصائح أخرى

From your description it looks like IIS deadlocks when it tries to acquire the session object for your request. I wouldn't be looking for a reason in the browsers because this can only be a server side issue. And probably one you can't do much about. If it is a deadlock, than it's a multi-threaded, timing dependent problem. So if different browsers send requests with slightly different timing, you get different results. Also if you run the browsers locally or remotely, you get slightly different timings. Emptying the session doesn't help because the problem is on session acquisition. Disabling the session completely does help, because the session isn't acquired at all. Changing the AppPool to Classic helps because it has a different implementation of Session management which doesn't have the deadlock. To test the hypothesis, you can try inserting an artificial delay between the postbacks on the client side. This will create different timing conditions and should affect the problem.

I have to say that these are just speculations based on your description and my experience with IIS. I would suggest that you change the AppPool to Classic because the performance downside aren't that huge.

I had a similar issue on my site. In my case I had a page that contained a number of grids that each called a asmx webservice to retrieve their data. If the user navigated away from the page before all of the web requests had completed, then that user's session could become very slow (at least a couple of minutes to load a page), but other users' sessions would be unaffected by the slowness. For me, the issue began when I installed .NET 4.5 on the server.

I found a page here: http://forums.asp.net/t/1888889.aspx/1?Question+regarding+a+possible+bug+within+NET+4+5 that talks about this being a known issue with .NET 4.5. The bug can be triggered if site is using integrated mode and the browser disconnects while waiting for a page that's using the ASP.NET session. (See post for more details).

I believe that your double-postback case might cause the browser to abandon one of the requests, so it seems like this would apply. In addition, I and others have noticed that the bug seems to be more commonly seen when using IE (although this is just a coincidence - it's not an IE bug)

The post also describes a workaround (adjusting the uploadReadAheadSize setting in the web.config), and that workaround solved the problem for me.

Please note that this is same as Stackoverflow post --> ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress.

This appears to be a regression in ASP.NET 4.5. ASP.NET team is working on a patch, but there is a temporary workaround (see the post referred above).

If you cannot wait for public broad update, you can contact Microsoft customer support for hotfix requests. Just follow the regular process of opening a support case. For example, file online https://support.microsoft.com/oas/default.aspx?&gprid=548&&st=1&wfxredirect=1&sd=gn or call support http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone. You may need to pay minimal amount upfront but you may get refund based on customer support policies. Just ask customer support professional to contact netfx45compat at Microsoft dot com to get quick context on this issue.

Thanks Varun Gupta (.NET Framework Compatibility)

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top