Deadlocks do aplicativo dentro do MVC usando o .NET 4.5 e IIS

9

Após atualizar recentemente um aplicativo para o .NET 4.5, comecei a notar um comportamento estranho relacionado a Controladores ( e suas Ações associadas ) sendo "bloqueado" durante as chamadas AJAX do Javascript.

Os problemas costumavam ser inconsistentes, mas resultariam se um Controlador estivesse sendo acessado por meio de uma chamada AJAX assíncrona e, durante esse pedido, outra chamada ( por meio de AJAX ou tradicionalmente ) fosse feita.

Isso fez com que a chamada original fosse "bloqueada" e normalmente demorava de 1 a 2 minutos até que o "impasse" fosse resolvido e as ações executadas como pretendido.

Exemplo de cenário

  • O usuário clica em um link que armazena temporariamente um valor na página ViewData a ser acessado na próxima solicitação.

  • Um redirecionamento ocorre e outro controlador é acessado ( como deveria ser ) e depois de carregar uma chamada AJAX é feita.

  • Durante esta chamada AJAX ( que acessa o valor ViewData corretamente ) uma chamada adicional é feita rapidamente ( como um usuário clicando imediatamente em um link para navegar para outro controlador ) . Depois de clicar neste link, o "deadlock" ocorrerá e o navegador não responderá.

    ou

  • A chamada será executada com sucesso ( desde que não seja interrompida por outra solicitação ), mas a tentativa de executar as etapas anteriores falhará.

Informações adicionais

  • Como mencionado, esse problema é bastante inconsistente, já que normalmente executado corretamente na primeira solicitação (a chamada AJAX ) como desde que não seja interrompido. No entanto, se você tentar fazer o mesma chamada novamente irá falhar.

  • Usando o Perfil de Navegador / Fiddler / Ferramentas de Desenvolvimento (F12), a segunda chamada AJAX está sendo feita, no entanto, ela nunca parece ser executada. (Mesmo colocando um ponto de interrupção dentro da chamada AJAX, no entanto, apesar da chamada ser feita, o ponto de interrupção nunca é atingido).

  • Esse problema ocorre APENAS dentro do Internet Explorer 9 ou abaixo.

  • O aplicativo está usando o MVC3, o .NET Framework 4.5, o IIS 7.5 e foi desenvolvido no Visual Studio 2012.

Soluções tentadas

  • SessionState - Tentou usar SessionStateBehavior.ReadOnly para evitar problemas de bloqueio que poderiam estar ocorrendo nos Controladores em questão.

  • Armazenamento temporário - Usado em vários meios diferentes para transmitir os valores temporários nos Controladores, como ViewData, Session e Cache.

  • ITempDataProvider - Atualmente, consideramos a implementação de um provedor para manipular quaisquer valores temporários, de modo que o projeto possa ser migrado para uma solução mais sem sessão.

Atualizar

Após consultar diversos membros da equipe do ASP.NET e alguns outros colaboradores da comunidade e determinar que o problema era, na verdade, um bug no .NET 4.5.

Você pode ler mais sobre o assunto em esta postagem do blog que eu escrevi sobre este mesmo tópico e a correção atualizada aqui .

    
por Rion Williams 07.03.2013 в 20:40
fonte

1 resposta

5

Temos tido problemas semelhantes em um ambiente de teste e produção. Temos notado que isso acontece apenas uma vez .net 4.5 está instalado. (Remoção de .net 4.5 corrige o problema.) Isso não acontece se você depurar seu aplicativo no Visual Studio Development Server ou definir o AppPool para o modo clássico. Parece estar relacionado ao IIS 7.5 e .net 4.5 com o AppPool no modo integrado.

Encontrei outras pessoas com problemas, mas sem resposta definitiva. O postback duplo do IE trava o IIS 7 no modo de pipeline do Integrated Managed quando a sessão é acessada

    
por Blane Bunderson 07.03.2013 / 22:19
fonte