Каковы некоторые рекомендации по управлению фоновыми потоками в IIS?

Question

Я написал HttpModule, который порождает фоновый поток. Я использую поток, как запланированное задание, которое выполняется в процессе, что очень удобно.

Каковы лучшие практики для отслеживания этой темы? Я никогда не делал этого раньше, и меня немного смущают некоторые аспекты этого:

1. Как узнать, работает ли еще поток? Я вижу, что он делает свою работу, но есть ли другой способ узнать, жив ли он еще? Я скачал ProcMon, но w3wp.exe порождает boatload потоков, поэтому я понятия не имел, какая у меня тема. Я назвал это, но это не помогло.

2. Как мне "поймать" нить, если она умирает? Есть ли какой-нибудь метод Dispose, где я могу записать его в EventLog или что-то в случае сбоя? «Умирающая декларация» или что-то?

3. Как мне активно остановить поток? Если я хочу, чтобы он прекратил выполнение этого фонового процесса, как мне его убить, не возвращая IIS?

4. Есть ли способ запустить его снова, независимо от HttpModule? (Я предполагаю, что ответ на этот вопрос нет ...)

Редактировать: Просто чтобы прояснить, предполагается, что моя нить никогда не исчезнет. Он запускает функцию, затем засыпает на пару минут, затем просыпается и снова запускает функцию. Это не так, как если бы он выполнял одну задачу, а потом заканчивал.

Answer 1

Когда Джефф сделал Stackoverflow, у него была похожая проблема.

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

Используя эту технику, вы легко получите ответы на свои вопросы:

1. Вы проверяете, что товар все еще находится в кэш.
2. Если предмет отсутствует в кеш, добавь его заново.
3. Удалить элемент кэша из кэша.
4. Добавить предмет возвращается в кеш.

Вы можете создать небольшую страницу управления для настройки этих параметров.

Это дает вам хороший способ приблизить время к ведению домашнего хозяйства в вашем веб-приложении. Это не требует отдельной службы Windows, что является большой победой.

Answer 2

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

Большим преимуществом является то, что служба Windows запускается с ОС, вы можете легко настроить, запустить и остановить ее с помощью панели управления, у вас есть встроенный мониторинг через журнал событий Windows, вы можете обновить фоновую службу и веб-приложение самостоятельно и т. д.

Если это не вариант, e. г. поскольку вы находитесь в среде общего хостинга, я бы порекомендовал следующее:

1. Запустите фоновый поток в Application_start (Global.asax) и сохраните ссылку на поток в статической переменной.
2. Оберните каждый метод, вызываемый в фоновом потоке, с помощью try / catch, поскольку начиная с .NET 2.0 каждое необработанное исключение в фоновом потоке будет закрывать приложение. (Он будет перезапущен при следующем запросе, но он замедляет следующий запрос, убивает все текущие сеансы и кэши и, конечно, таймер не будет активен до следующего запроса.)
3. При каждом запросе (реализованный имеет HttpModule или снова в Global.asax), проверьте экземпляр Thread в глобальной переменной (это все еще! = Null, поток активен и работает и т. Д.). Если нет, вызовите код перезагрузки. Используйте блокировку в части перезапуска, чтобы убедиться, что поток не будет создан дважды одновременно.

Даже тогда вы не можете быть уверены, что ваш фоновый поток всегда работает, если у вас нет регулярного трафика круглосуточно. Также имейте в виду, что в среде общего хостинга очень часто закрываются пулы приложений, если в течение нескольких часов не выполняется никаких действий. Вы можете попытаться улучшить это, настроив запланированное задание на клиентском компьютере в собственной сети, выполняя легкий запрос HTTP для вашего приложения каждые несколько минут, просто чтобы убедиться, что ваше приложение всегда работает.