Unsere Protokolle melden ThreadAbortException s, die unsere Quartz.NET-Jobs in scheinbar zufälligen Intervallen stoppen. Soweit ich weiß, würde dies normalerweise nicht durch etwas verursacht werden, das der Thread selbst tut (z. B. Lesen einer Datei von einem FTP-Server oder Ausführen einer LINQ to Entities-Abfrage), sondern weil ein äußerer Prozess dem Thread sagt, dass er aufhören soll . Außerdem führt die Art und Weise, wie die Logs erstellt werden, zu der Annahme, dass die gesamte Webanwendung neu gestartet wird, wenn diese Fehler auftreten. Daher vermute ich, dass der Neustartprozess dazu führt, dass der Thread überhaupt abgebrochen wird / p>
Meine Frage ist also: Wie kann ich herausfinden, warum der Server / die Anwendung neu gestartet wird? Gibt es irgendwo Protokolle, die mir bei jedem Neustart Details geben würden? Gibt es gemeinsame Ursachen für so etwas, das ich untersuchen sollte?
Vielen Dank im Voraus für Ihre Hilfe.
Bearbeiten
Ich hatte gerade eine Diskussion mit einigen Kollegen, und es klingt, als würde IIS die Anwendung nach einer gewissen Zeit der Inaktivität automatisch in den Ruhezustand versetzen, was ein Teil des Problems sein könnte. Mit einigen Nachforschungen habe ich eine Einstellung für "Idle Timeout" für Worker-Threads in IIS gefunden. Ich denke, wenn die Anwendung für einen bestimmten Zeitraum keine Anforderungen verarbeitet hat, gibt sie einen Befehl zum Herunterfahren aus. Aus irgendeinem Grund wird Quartz nicht sofort heruntergefahren, sondern wartet darauf, dass der nächste Job ausgelöst wird, und dann erkennt das System den Thread des Jobs und beendet ihn, während er versucht, ihn auszuführen.
Ich denke also, wir müssen uns etwas einfallen lassen, um alle laufenden Jobs ordnungsgemäß zu beenden, wenn das System herunterfahren will, und Quartz tatsächlich herunterfahren, wenn es angewiesen wird, wenn es keine Jobs ausführt. Hat jemand Erfahrung mit dieser Art von Problem?
Wie liho1eye sagte, entstand das Problem aus dem Anwendungspool, der unsere Anwendung herunterfährt. Aus irgendeinem Grund wurde Quartz offenbar nicht sofort stillgelegt. Stattdessen hat es gewartet, bis der nächste Job ausgeführt und dann heruntergefahren wurde, was bedeutete, dass der laufende Job über ThreadAbordException heruntergefahren werden musste.
Unsere Lösung dafür war zweifach. Zuerst haben wir Quartz auf eine neuere Version aktualisiert, die es scheinbar ein wenig besser aussehen ließ. Zweitens haben wir in unserer Application_End-Methode in Global.asax.cs einen Aufruf von Scheduler.Shutdown(true) hinzugefügt. Dies weist den Scheduler an, das Auslösen weiterer Trigger zu stoppen, und wartet dann, bis alle aktuell ausgeführten Trigger abgeschlossen sind, bevor die Anwendung beendet wird.
Das bedeutet natürlich, dass irgendwo in der Instanz Ihres Jobthreads Thread.Abort() heißt. Ich würde auf diese Quarz-Sache zur Erklärung schauen.
Eine andere Möglichkeit ist, dass Ihr Job-Thread ein Hintergrund-Thread ist und Ihr App-Pool recycelt wird, aber ich würde alles über diese Quartz-Sache sicher wissen.
Wenn Sie in Ihrem Code Umleitungen durchführen, ohne den Parameter endReponse von Response.Redirect anzugeben, ruft die Umleitung thread.Abort () auf, aber es wird weiterhin Code zur Ausführung vorhanden sein. Dieser Code wird verwaist, da der Thread weg ist und Sie die Ausnahme erhalten. Zum Lesen:
Bearbeiten:
Eine andere Möglichkeit wäre eine nicht behandelte Ausnahme auf Serverebene, die dazu führt, dass der Prozess w3wp.exe zum Absturz bringt oder sich selbst recycelt . Dies wäre der externe Grund, auf den Sie hingewiesen haben, der dazu führen würde, dass der Thread abbricht, aber versucht, den Code weiter auszuführen. Um festzustellen, ob dies der Fall sein könnte, würden Sie Ausnahmen in Ihrem Systemereignisprotokoll haben. Sie sind sehr generisch, aber sie werden w3wp.exe klar auflisten (damit Sie das als Filter verwenden können). Wenn dies der Fall ist, müssen Sie IIS Debug Diagnostics und richten Sie einige Absturzmonitore ein, um festzustellen, was im Moment des Absturzes passiert. Da dies außerhalb des eigentlichen Seitenlebenszyklus geschieht, wird die normale Ausnahmebehandlung umgangen.