asp.net - usetaskfriendlysynchronizationcontext - iis async task




Warum löst meine asp.net-Anwendung ThreadAbortException aus? (4)

selbsterklärende Frage.

Warum sprudelt dieses Ding in meinen try catch, selbst wenn nichts falsch ist?

Warum taucht es hunderte Male in meinem Protokoll auf?

Ich weiß, es ist eine newb Frage, aber wenn diese Seite Such-Ranking bekommen und newbs eintragen wird, müssen wir sie fragen




Der Grund dafür, warum Response.Redirect diese Ausnahme gibt, ist, dass asp.net diese API intern mit Thread.Abort () implementiert. Wenn diese Methode aufgerufen wird, wird eine spezielle ThreadAbortException ausgelöst. Diese Ausnahme wird nicht von einem catch-Block geschluckt. Es wird am Ende jedes Catch-Blocks neu geworfen.


Da ich weiß, dass es (mindestens) drei APIs gibt, die Thread.Abort intern verwenden, würde ich gerne Thread.Abort antworten, wie ich herausfinden kann, was ich dagegen tun kann.

Für uns wurde dieser Fehler plotzlich protokolliert. Was hat sich geändert? Wir haben einen Fehler in einigen Datenbankprozeduren behoben, die mit Sitemaps zu tun hatten.

Die Log4net-Logs zeigten, dass der X-Forwarded-For-Header (wir sind hinter einem NLB) die IP-Adresse des Googlebots 66.249.78.x war, die meine Theorie über die Sitemap-Änderung unterstützte, die dazu führte, dass Google unsere Website aggressiver nach Bildern durchforstete.

Als Erstes wurde herausgefunden, warum nur der Googlebot dieses Problem verursachen konnte. Kein anderer Client hat ausgelöst, was auch immer der Codepfad verwendet. Response.Redirect oder was auch immer.

Daher HttpApplication.Error ich im HttpApplication.Error Handler etwas Code hinzugefügt, um eine extra detaillierte Ausgabe mit allen Headern zu protokollieren, und die meisten Daten in HttpResponse und HttpContext , um protokolliert zu werden.

Das Problem war, dass der Googlebot eine iPhone-User-Agent-Zeichenfolge verwendet und damit bewaffnet war. Ich war in der Lage, die Codebasis nach "iPhone" zu durchsuchen und Folgendes zu finden:

private void CheckIPhoneAccess() { ... }

Und das benutzt einen Redirect.

Was dagegen?

Nun, für diese veraltete Codebase lohnt es sich nicht, alle Response.Redirect Aufrufe zu ThreadAbortException , also werde ich die Protokollierungsebene für ThreadAbortException für die Anwendung ThreadAbortException .

Ich werde das Verhalten für den mobilen Crawler des Googlebot ändern, was nicht zu "Lügen" darüber führt, was unsere Website für Mobilgeräte bereitstellt, da sie nur auf den ersten Treffer umleitet, anschließend einen Cookie liest und das Bild anzeigt. Der Googlebot scheint diesen Cookie nicht im Cache zu speichern.

Es ist nicht perfekt, aber die Website soll wieder aufgebaut werden. wahrscheinlich von einem anderen Team, das Scala oder so benutzt, also denke ich, dass dies eine gute Wahl ist. Ich werde Kommentare hinzufügen und das Problem später erneut untersuchen. Erstellen Sie eine Response.SafeRedirect Erweiterung, die diesen Ratschlag enthält:

Warum verursacht Response.Redirect System.Threading.ThreadAbortException?

Lukas





multithreading