Original uploaded to flickr by TaranRampersad

Bei der Entwicklung unseres ASP.NET / AJAX basierenden Projektmanagement-Problems stießen wir gestern auf eines dieser lustigen Probleme, die an sich eine simple Ursache haben, aber erst einmal stundenlanges Nachforschen mit sich bringen. Folgendes war passiert:

Abgesehen vom internen Entwicklungs-Webserver des Visual Studio 2005 nutzen wir zum Test der Entwicklung auch einen IIS 5 auf unserem lokalen Development-Server. Bevor der aktuelle Entwicklungsstand auf die Produktivmaschine deployed wird erfolgt hier noch einmal ein halbwegs gründlicher Vorab-Test – und gegebenenfalls kann man so auch relativ simpel "IIS-spezifische" Probleme debuggen. Alles funktionierte prima. Auf der Produktiv-Maschine traten jedoch plötzlich und nicht wirklich reproduzierbar seltsame Fehler im Verhalten der Web-Oberfläche auf. Nach einigem Herumgerate instrumentalisierte ich die Global.asax mit ins Eventlog schreibendem Diagnostik-Code. Mit dessen Hilfe wurde recht schnell deutlich, was hier schief lief:

Anscheinend wurden ständig neue Sessions und auch neue Applications gestartet, wenn der Benutzer mit der Anwendung interagierte. Mitunter landeten Aktionen zwar auch in der richtigen Session (und alles funktionierte wie gewünscht), oftmals aber auch nicht. Der Status der Anwendung ging somit natürlich komplett flöten.

Nach einigem Herumprobieren, Überlegen und Recherchieren war dann die Wurzel des Übels gefunden: Auf der Produktiv-Maschine läuft die Anwendung in einem IIS 6. Dieser bietet eine Menge toller, neuer Features wie z.B. mehere Worker-Prozesse und deren automatisiertes Recycling, mehrere unabhängige Application Pools sowie hübsche Web Gardens. Der Haken daran: Komplexe ASP.NET-Anwendungen laufen aufgrund des ASP-eigenen Session-Managements eigentlich nur dann stabil, wenn man auf alle diese Neuerungen verzichtet. Das Hauptproblem ist dabei das InProc – Session State Management, mit welchem ASP.NET-Anwendungen per Default laufen. Stellt man dieses auf den ASP.NET State Server um, welcher als separater Dienst außerhalb des IIS läuft, wird die Sache schon wesentlich besser. Allerdings hatten wir immer noch Probleme, wenn wir mehr als einen Worker-Prozess zu ließen, da bei PostBacks gelegentlich noch neue Applications gestartet wurden. Nachdem nur noch ein einziger davon zugelassen war lief die Anwendung aber sauber und stabil.

Update: Ein paar weiterführende Informationen zum Thema Session State Management im IIS 6 habe ich hier zusammen gefasst.