Sie befinden sich aktuell in den Dr. Jochen Manns Blog-Archiven für den folgenden Tag 14.3.2009.
14.3.2009 von JMS.
Die einfachste Methode, ASP.NET zu hosten ist es, den HttpListener als HTTP Protokollschicht einzusetzen (wenn man nicht gerade eine eigene Implementierung schreiben will). Allerdings gibt es hier einen kleinen Haken: der HttpListener scheint an den Thread gebunden zu sein, der ihn gestartet hat (Start oder BeginGetContext).
Startet man den Listener auf dem Haupthread der Anwendung, funktioniert alles wie gewünscht und der Listener erkennt automatisch das Ende der Anwendung. So weit so gut. Wenn man allerdings einen Thread verwendet, der explizit oder implizit beendet wird, so terminiert auch der Listener. In meinem Fall knallte es beim expliziten Beenden: ich hatte einen Thread, der einfach nur den Listener konfigurierte und startet und sich dann beendet - damit die Initialisierung der Anwendung (in diesem Fall der VCR.NET Windows Dienst) im Hauptstrang so schnell wie möglich durchläuft.
Mit ThreadPool.QueueUserWorkItem geht es dann, aber mit einer im Hintergrund drohenden Gefahr: der ThreadPool beendet die Aufgabe und verwendet den Thread dann später für andere Aufgaben weiter. Der Listener bleibt an diesen Thread gebunden, der überhaupt nichts mehr mit ihm zu tun hat. Und wenn der ThreadPool irgendwann mal einen Thread wegwirft? Den Fehler findet man vermutlich nie!
Ich habe mich daher entschieden, mich nicht auf die Willkür zu verlassen und halte den Thread, der den Listener hochfährt, bis zum Ende der Anwendung oben (über ein Manual/AutoResetEvent). Nur so habe ich ein gutes Gefühl, dass nicht doch plötzlich die Kommunikation des Clients zum ASP.NET zusammenbricht.
Zumindest sollte man das im Hinterkopf haben!
Jochen
Geschrieben in .NET, VCR.NET | Keine Kommentare »