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