Anwendungs-Deadlocks in MVC mit .NET 4.5 und IIS

9

Nachdem ich kürzlich eine Anwendung auf .NET 4.5 aktualisiert hatte, bemerkte ich ein merkwürdiges Verhalten bei Controllern ( und den zugehörigen Aktionen ), die während AJAX-Aufrufen aus Javascript "blockiert" wurden.

Die Probleme waren oft inkonsistent, würden aber auftreten, wenn auf einen Controller über einen asynchronen AJAX-Aufruf zugegriffen würde und während dieser Anfrage ein anderer Aufruf ( durch AJAX oder traditionell ) erfolgte.

Dies führte dazu, dass der ursprüngliche Aufruf "blockiert" wurde und es normalerweise 1-2 Minuten dauerte, bis dieser "Deadlock" behoben wurde und die Aktionen wie geplant ausgeführt wurden.

Beispielszenario

  • Der Benutzer klickt auf einen Link, der vorübergehend einen Wert im
    speichert ViewData, auf die bei der nächsten Anfrage zugegriffen wird.

  • Eine Weiterleitung erfolgt und auf einen anderen Controller wird zugegriffen ( wie es sein sollte ) und nach dem Laden wird ein AJAX-Aufruf durchgeführt.

  • Während dieses AJAX-Aufrufs (, der den ViewData-Wert richtig aufruft ) wird schnell ein weiterer Aufruf ausgeführt ( wie ein Benutzer, der sofort auf einen Link klickt, um zu einem anderen Controller zu navigieren ) . Nach dem Klicken auf diesen Link wird der "Deadlock" auftreten und der Browser wird nicht mehr reagieren.

    oder

  • Der Aufruf wird erfolgreich ausgeführt (, solange er nicht von einer anderen Anforderung unterbrochen wird), aber der Versuch, die vorherigen Schritte auszuführen, schlägt fehl.

Zusätzliche Informationen

  • Wie bereits erwähnt, ist dieses Problem ziemlich inkonsequent normalerweise ordnungsgemäß bei der ersten Anfrage (der AJAX-Aufruf ) als ausgeführt wird solange es nicht unterbrochen wird. Wenn Sie jedoch versuchen, die derselbe Anruf wird erneut fehlschlagen.

  • Mit dem Browser Profiler / Fiddler / Entwicklungstools (F12) wird der zweite AJAX-Aufruf durchgeführt, der jedoch nie ausgeführt wird. (Auch wenn ein Breakpoint innerhalb des AJAX-Aufrufs platziert wird, wird der Breakpoint trotz des Aufrufs nie getroffen.)

  • Dieses Problem tritt NUR in Internet Explorer 9 oder darunter auf.

  • Die Anwendung verwendet MVC3, .NET Framework 4.5, IIS 7.5 und wurde in Visual Studio 2012 entwickelt.

Lösungsversuche

  • SessionState - Es wurde versucht, SessionStateBehavior.ReadOnly zu verwenden, um Blockierungsprobleme zu vermeiden, die bei den fraglichen Controllern auftreten könnten.

  • Temporärer Speicher - Verwendete verschiedene Methoden zum Übergeben der temporären Werte über die Controller, z. B. ViewData, Session und Cache.

  • ITempDataProvider - Es wird derzeit erwogen, einen Provider für die Verarbeitung temporärer Werte zu implementieren, damit das Projekt in eine Sessionless-Lösung migriert werden kann.

Aktualisieren

Nach Rücksprache mit mehreren Mitgliedern des ASP.NET-Teams und einigen anderen Community-Mitarbeitern wurde festgestellt, dass das Problem tatsächlich ein Fehler in .NET 4.5 war.

Sie können mehr über das Problem in diesen Blogeintrag, den ich zu diesem Thema und dem Update hier geschrieben habe .

    
Rion Williams 07.03.2013, 19:40
quelle

1 Antwort

5

Wir hatten ähnliche Probleme in einer Test- und Produktionsumgebung. Wir haben festgestellt, dass es nur einmal passiert .net 4.5 ist installiert. (Durch das Entfernen von .net 4.5 wird das Problem behoben.) Dies tritt nicht auf, wenn Sie Ihre Anwendung in Visual Studio Development Server debuggen oder den AppPool auf den klassischen Modus festlegen. Es scheint mit IIS 7.5 und .net 4.5 mit AppPool im integrierten Modus verwandt zu sein.

Ich habe andere Leute gefunden, die Probleme haben, aber keine definitive Antwort. IE Double Postback hängt IIS 7 im integrierten verwalteten Pipeline-Modus, wenn auf die Sitzung zugegriffen wird

    
Blane Bunderson 07.03.2013, 21:19
quelle

Tags und Links