Вот моя среда: IIS7.5 на Win 7, .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 на Windows Server 2008 R2 с установленным .Net 4.5
- 7.5.7600.16385 в Windows 7 Pro с установленным .Net 4.5
Версия IE протестирована
- 9.0.8112.16421 в Windows 7 Pro
- 8.0.7600.16385 в Windows Server 2008 R2
- 6.0.3790.3959 в Windows Server 2003 SP2
Я заметил аномалию, заключающуюся в том, что при доступе к локальному IIS 8.0.7600.16385 в Windows Server 2008 R2 НЕ вызывает эту проблему с блокировкой. Но если я использую браузер для доступа к удаленному IIS, проблема может быть воспроизведена. В IE 9 я могу воспроизвести проблему независимо от того, находится ли IIS удаленно или локально.
Вот снимок экрана, на котором показано, как зависший запрос выглядит в списке запросов для рабочего процесса.
Теперь мы нашли несколько способов обойти эту проблему, но ни один из них не является приемлемым в нашей ситуации:
- Удалить / закомментировать использование сеанса.
- Измените пул приложений на классический режим.
ПРИМЕЧАНИЕ: мы также обнаружили, что даже если мы не используем сеанс напрямую, как показано в примере, проблема все равно возникает. IE: если мы добавим Global.asax.cs и пустой обработчик событий Session_Start, запрос все равно будет зависать в RequestAcquireState.
Кто-нибудь знает, почему это происходит и как решить эту проблему, которая, похоже, возникает только в режиме интегрированного управляемого конвейера?
