2009-04-24 6 views
0

Ich sehe ein sehr seltsames Problem auf einer meiner Produktion Boxen. Wir haben eine Anwendung in IIS 6 auf einem einzelnen Computer mit einem Apache-Webserver vor ihm gehostet. Meine Anwendung verwendet die ASP.NET-Mitgliedschaft für die Authentifizierung und verwendet den Sitzungsstatus. Ich sehe gerade ein Problem, bei dem einige Serveranforderungen beim Versuch, auf Sitzungsvariablen zuzugreifen, eine Null-Ausnahme erleiden. Wenn die Anforderung jedoch wiederholt wird, trifft die Seite keine Ausnahmen und verhält sich ordnungsgemäß.ASP.NET-Sitzung für eine Anfrage verlieren und dann wieder bei nächsten

Ich glaube, das hat etwas damit zu tun, dass das Session ID Cookie entweder beschädigt wird oder auf der Anfrage verloren geht, aber ich habe keine Ahnung, was das verursachen könnte. Der Grund dafür liegt meiner Meinung nach darin, dass es so aussieht, als würde ASP.NET den Cookie nicht sehen und keine neue Sitzung erstellen, was erklären würde, warum die Variablen null sind. Wenn die Ausnahme auftritt, kann das neue SessionID-Cookie nicht zurück auf den Client geschrieben werden, sodass der Client weiterhin die ursprüngliche SessionID behält. Wenn dann die nächste Anfrage gesendet wird, wird das ursprüngliche SessionID-Cookie verwendet, das jetzt ASP.NET findet und in der Lage ist, den Sitzungsstatus abzurufen. Dies ist reine Spekulation, scheint aber den Symptomen zu entsprechen.

Auch diese Website verwendet keine anderen Cookies als die, die von ASP.NET Mitgliedschaft und ASP.NET Sitzung benötigt werden, also bin ich unter der Cookie-Grenze für IE. Die Website funktioniert seit etwa 8 Monaten einwandfrei und dieses Problem tauchte kürzlich auf. Ich habe versucht, IIS zurückgesetzt und tatsächlich den Computer neu gestartet, aber nichts scheint das Problem zu helfen.

Updates:

Hier sind einige Präzisierungen, die gebeten wurden.

1.) Unser Apache-Server ist das einzige, was dem Internet ausgesetzt ist. Alle Anfragen erfolgen über HTTPS zu dieser Box. Die Apache-Box leitet dann alle Anfragen über HTTP an unseren Anwendungsserver weiter. Dies wird aus Sicherheitsgründen getan. Wir haben nachgesehen, ob Apache das Problem war, aber es scheint keinen Fehler in den Apache-Protokollen zu geben.

2.) Die Null-Ausnahme tritt auf, wenn versucht wird, auf ein in der Sitzung gespeichertes Objekt zuzugreifen, das von der Anwendung erwartet wird, im Gegensatz zu der Ausnahme, die mit dem eigentlichen Sitzungsobjekt selbst auftritt.

+0

Sie leiten Anforderungen aus einer Apache-Box aus Sicherheitsgründen an eine IIS-Box weiter? Ich glaube nicht, dass Ihre Netzwerk-Jungs wissen, was sie tun. – NotMe

+0

Wir haben eine DMZ-Zone, die im Grunde eine andere Ebene vor unseren Anwendungen ist, damit sie nicht dem Netz ausgesetzt sind. Es ermöglicht auch das Umschreiben von URLs, die Sie wirklich nicht mit einem .NET-Technologie-Stack machen können, es sei denn, Sie aktualisieren auf IIS7. – Broc

+0

Können Sie Ihre Einrichtung klären? Ich habe keine Ahnung, was Sie mit IIS 6 "mit einem Apache-Webserver davor meinen". Was behandelt HTTP-Anfragen eigentlich aus dem Internet? Ist die Null-Ausnahme für das tatsächliche Session-Objekt oder nur, dass die Objekte, die Sie in der Sitzung erwarten, nicht vorhanden sind? Eines dieser Dinge ... sollte niemals passieren! Selbst wenn das Session-ID-Cookie verloren gegangen ist, sollte ASP.NET ein neues gültiges Session-Objekt erstellen. – Bryan

Antwort

0

Wir haben die Ursache des Problems gefunden. Es sieht so aus, als wäre die IIS-Metabasis auf unserem App-Server beschädigt worden. Der beste Weg, dieses Problem zu beheben, besteht darin, eine Neuinstallation von IIS durchzuführen. Dies ist jedoch aufgrund von geschäftlichen Einschränkungen für uns keine Option. Eine andere Lösung besteht darin, einfach einen neuen App-Pool zu erstellen, unter dem die Anwendung ausgeführt werden kann. Laut einigen Leuten, die mehr IIS-Kenntnisse haben als ich selbst, wird dies das Problem kurzfristig beheben, aber es ist sehr wahrscheinlich, dass dasselbe mit diesem App-Pool passieren wird. Daher müssen wir neue App-Pools erstellen, wenn dies erneut auftritt.

Verwandte Themen