Как я могу узнать, почему мой поток останавливается в ASP.NET?

Question

Наши журналы сообщают о ThreadAbortException с, которые останавливают наши задания Quartz.NET с, казалось бы, случайными интервалами.Из того, что я понимаю, это обычно не вызвано чем-то, что делает сам поток (например, читает файл с FTP-сервера или выполняет запрос LINQ to Entities), а скорее потому, что какой-то внешний процесс говорит потоку остановиться,Более того, то, как создаются журналы, заставляет меня поверить, что веб-приложение перезапускается, когда мы получаем эти ошибки, поэтому я предполагаю, что процесс перезапуска - это то, что в первую очередь приводит к прерыванию потока.

Итак, мой вопрос: как я могу выяснить, почему сервер / приложение перезапускается?Где-нибудь есть журналы, которые бы давали мне подробности о каждом перезапуске?Есть ли общие причины для чего-то подобного, которые я должен расследовать?

Заранее благодарен за вашу помощь.

Редактировать

Я только что провел обсуждениес некоторыми сотрудниками, и похоже, что IIS автоматически переводит приложение в спящий режим после определенного периода бездействия, что может быть частью проблемы.В результате некоторых исследований я обнаружил параметр Idle Timeout для рабочих потоков в IIS.Я думаю, что, когда приложение не обрабатывает какие-либо запросы в течение определенного периода времени, оно выдает команду завершения работы.По какой-то причине Quartz не закрывается немедленно, а вместо этого ждет следующего задания, которое запускается, а затем система обнаруживает поток этого задания и убивает его во время его запуска.

Так что, я думаю, мыНужно найти какой-то способ, чтобы изящно завершать любые запущенные задания, когда система хочет завершить работу, и заставить Quartz фактически выключаться, когда ему говорят, если он не выполняет какие-либо задания.У кого-нибудь есть опыт с такого рода проблемами?

Answer 1

Как указал liho1eye, проблема возникла из-за того, что пул приложений закрывал наше приложение. По какой-то причине Кварц явно не закрывался сразу. Вместо этого он ждал, пока следующее задание не будет запущено, и затем завершил работу, что означало, что выполняемое задание должно было быть закрыто через ThreadAbordException.

Наше решение было двояким. Во-первых, мы обновили Quartz до более новой версии, которая, казалось, заставила его вести себя немного лучше. Во-вторых, в нашем методе Application_End в Global.asax.cs мы добавили вызов Scheduler.Shutdown(true). Это указывает планировщику прекратить запуск дополнительных триггеров, а затем ожидает завершения всех запущенных в данный момент триггеров, прежде чем приложение завершится.

Answer 2

Естественно, это означает, что что-то, называемое Thread.Abort() в экземпляре вашей цепочки заданий. Я бы посмотрел на эту Кварцевую вещь для объяснения.

Другая возможность состоит в том, что ваш рабочий поток является фоновым потоком, а ваш пул приложений перерабатывается, но я бы знал что-нибудь об этом Кварце, чтобы сказать наверняка.

Answer 3

Если вы выполняете какие-либо перенаправления в своем коде без указания параметра endReponse в Response.Redirect, перенаправление вызовет thread.Abort (), но все равно будет код для выполнения. Этот код становится осиротевшим, так как поток исчез, и вы получите исключение. Для чтения:

http://www.c6software.com/articles/ThreadAbortException.aspx

Редактировать:
Другая возможность - необработанное исключение уровня сервера, которое вызывает сбой процесса w3wp.exe или перезапускает себя . Это будет внешней причиной, на которую вы ссылались, что приведет к прерыванию потока, но попытке продолжить выполнение кода. Чтобы определить, так ли это, у вас должны быть исключения в журнале системных событий. Они очень общие, но в них будет четко указан w3wp.exe (так что вы можете использовать его в качестве фильтра). Если это так, вам нужно установить Диагностика отладки IIS и настроить несколько мониторов сбоя, чтобы отследить, что происходит в момент сбоя. Поскольку это происходит вне реального жизненного цикла страницы, обычная обработка исключений игнорируется.