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
- 7.5.7600.16385 on Windows Server 2008 R2 with .Net 4.5 Installed
- 7.5.7600.16385 on Windows 7 Pro with .Net 4.5 Installed
IE version tested
- 9.0.8112.16421 on Windows 7 Pro
- 8.0.7600.16385 on Windows Server 2008 R2
- 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.
Now we have found a few ways to get around this problem, but none are acceptable in our situation:
- Remove/Comment out Session usage.
- 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?