20

Вот моя среда: IIS7.5 на Win 7, .NET 4, App Pool IntegratedIE двойной постбэк висит IIS 7 в интегрированном режиме Managed трубопровода, когда сеанс доступен

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 тестируемых

  1. 7.5.7600.16385 на Windows Server 2008 R2 с .Net 4.5 Установленные
  2. 7.5.7600.16385 на Windows 7 Pro с .Net 4.5 Installed

IE протестировали версию

  1. 9.0.8112.16421 на Windows 7 Pro
  2. 8.0.7600.16385 на Windows Server 2008 R2
  3. 6.0.3790.3959 на Windows Server 2003 с пакетом обновления 2

Аномалия я заметил, это то, что при обращении к местному IIS , 8.0.7600.16385 на Windows Server 2008 R2 НЕ вызывает эту проблему блокировки. Но если я использую браузер для доступа к удаленному IIS, тогда проблема может быть воспроизведена. Хотя в IE 9 я могу воспроизвести проблему независимо от того, находится ли IIS на удаленном или локальном.

Вот скриншот того, как выглядел повешенный запрос в списке запросов для рабочего процесса.

Stuck Requests Теперь мы нашли несколько способов, чтобы обойти эту проблему, но ни один не являются приемлемыми в нашей ситуации:

  1. Remove/Закомментируйте использование сеанса.
  2. Изменение пула приложений в классическом режиме.

ПРИМЕЧАНИЕ. Мы также обнаружили, что даже если мы не используем непосредственно сеанс, как показано в примере, проблема все еще возникает. IE: если мы добавим файл Global.asax.cs и добавим пустой обработчик событий Session_Start, запрос все равно будет зависать в RequestAcquireState.

Кто-нибудь знает, почему это происходит и как мы можем решить эту проблему, которая, по-видимому, происходит только в режиме интегрированного управляемого конвейера?

+0

Я не могу воспроизвести это на IIS7.5 на Win7 x64. Является ли apppool пулом приложений по умолчанию? Веб-сайт веб-сайта по умолчанию? – rene

+0

Этот пример кода, который вы предоставили, позволяет воспроизвести проблему? Я спрашиваю, потому что это сработало для меня. Фактически, используя сетевой мониторинг в инструментах разработчика IE, он ясно показывает, что второй запрос прерывается, что, вероятно, не происходит в вашем случае, следовательно, проблема. Кроме того, не должен ли это быть IIS 7.5 - я не думаю, что вы можете получить IIS 7 для Windows 7. –

+0

Что я наблюдаю в сетевом мониторинге инструментов IE dev, заключается в том, что первый запрос будет прерван, второй запрос будет продолжен, но он не вернется. Проблема может не возникнуть при первой попытке, поэтому продолжайте нажимать кнопку, чтобы наблюдать за проблемой, я обновлю исходный вопрос. – BlueFox

ответ

4

Хорошие новости! Похоже, что проблема блокировки сеанса была решена после установки .Net 4.5.1

Я обновил свою тестовую машину 7.5.7600.16385 на Windows Server 2008 R2 с .Net 4.5, установленным до версии 4.5.1, и проблема исчезла !

8

Из вашего описания это похоже на тупики IIS, когда он пытается получить объект сеанса для вашего запроса. Я бы не искал причины в браузерах, потому что это может быть только проблема на стороне сервера. И, вероятно, вы не можете многое сделать. Если это тупик, это многопоточная проблема, зависящая от времени. Поэтому, если разные браузеры отправляют запросы с небольшим разным временем, вы получаете разные результаты. Кроме того, если вы запускаете браузеры локально или удаленно, вы получаете несколько разные тайминги. Опорожнение сеанса не помогает, поскольку проблема связана с получением сеанса. Отключение сеанса полностью помогает, потому что сеанс вообще не получен. Изменение AppPool в Classic помогает, потому что у него есть другая реализация управления сеансом, которая не имеет взаимоблокировки. Чтобы проверить гипотезу, вы можете попробовать вставить искусственную задержку между обратными передачами на стороне клиента. Это создаст различные временные условия и должно повлиять на проблему.

Должен сказать, что это только предположения, основанные на вашем описании и моем опыте работы с IIS. Я бы предположил, что вы изменили AppPool на Classic, потому что недостаток производительности не настолько огромен.

+0

+1 Хороший ответ. Неприятная проблема. –

+0

У меня была проблема с тупиком, подобная этому. Я изменил с пула приложений по умолчанию на ASP.NET v4.0, и он ушел. – Zoidberg

5

У меня была аналогичная проблема на моем сайте. В моем случае у меня была страница с несколькими сетками, каждая из которых называлась веб-службой asmx для извлечения своих данных. Если пользователь перешел от страницы до того, как все веб-запросы были завершены, сеанс этого пользователя может стать очень медленным (по крайней мере, пару минут для загрузки страницы), но сеансы других пользователей не будут затронуты медленностью. Для меня проблема началась, когда я установил .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. (См. Сообщение для получения дополнительной информации).

Я считаю, что ваш случай с двойной обратной связью может заставить браузер отказаться от одного из запросов, поэтому похоже, что это применимо. Кроме того, я и другие заметили, что ошибка, по-видимому, чаще встречается при использовании IE (хотя это просто совпадение - это не ошибка IE)

Сообщение также описывает обходное решение (настройка параметра uploadReadAheadSize в web.config), и этот обходной путь решил проблему для меня.

+0

Да; звучит как проблема (http://stackoverflow.com/questions/11250167/how-can-i-debug-sessionstatemodule-request-aquire-state-taking-100-seconds-on). Похоже на ошибку ASP.NET; возможно, проблема 6, упомянутая здесь: http://support.microsoft.com/kb/2828841/en-us –

1

Обратите внимание, что это то же самое, что и столбец Stackoverflow ->ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress.

Это, по-видимому, регрессия в ASP.NET 4.5. Команда ASP.NET работает над патчем, но существует временное решение (см. Сообщение выше).

Если вы не можете дождаться публичного широкоформатного обновления, вы можете обратиться в службу поддержки клиентов Microsoft за исправлениями. Просто следуйте регулярному процессу открытия дела поддержки. Например, файл онлайн https://support.microsoft.com/oas/default.aspx?&gprid=548&&st=1&wfxredirect=1&sd=gn или поддержку вызова http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone. Возможно, вам придется заплатить минимальную сумму авансом, но вы можете получить возмещение по политикам поддержки клиентов. Просто обратитесь к специалисту по поддержке клиентов, чтобы связаться с netfx45compat в Microsoft dot com, чтобы получить быстрый контекст по этой проблеме.

Благодаря Varun Gupta (.NET Framework) Совместимость