У меня есть ASP.NET приложение работающее на IIS 6. Иногда (нечасто) у него будет необходимость запустить 'длинную' (до 3 мин) задачу — запись пачки данных в БД. Я знаю что такие вещи положено выносить из ASP-приложения вовне — например в сервис. Тем не менее передо мной поставлена задача сделать это в рамках ASP-приложения. Для этого я планирую создать либо поток через "new Thread(...)", либо использовать ThreadPool ASP-приложения.
Тем не менее я не знаю точно что случится если в момент когда моя 'длинная' задача будет работать, кто-то захочет остановить ASP.NET ApplicationPool (вручную или произойдёт периодический Recycling). Ну или весь IIS перезапустят.
Что будет by default — IIS будет ждать пока моя задача не завершится? Или он будет ждать только некоторое время а потом просто убьет мой поток? Как мне правильно обрабатывать такую ситуацию? Application_End вызовется ДО убийства потока занятого моей задачей? Что делает IIS с накопившимися в ThreadPool-е заданиями — просто теряет их?
Здравствуйте, Glenn, Вы писали:
G>У меня есть ASP.NET приложение работающее на IIS 6. Иногда (нечасто) у него будет необходимость запустить 'длинную' (до 3 мин) задачу — запись пачки данных в БД. Я знаю что такие вещи положено выносить из ASP-приложения вовне — например в сервис. Тем не менее передо мной поставлена задача сделать это в рамках ASP-приложения. Для этого я планирую создать либо поток через "new Thread(...)", либо использовать ThreadPool ASP-приложения.
G>Тем не менее я не знаю точно что случится если в момент когда моя 'длинная' задача будет работать, кто-то захочет остановить ASP.NET ApplicationPool (вручную или произойдёт периодический Recycling). Ну или весь IIS перезапустят.
G>Что будет by default — IIS будет ждать пока моя задача не завершится? Или он будет ждать только некоторое время а потом просто убьет мой поток? Как мне правильно обрабатывать такую ситуацию? Application_End вызовется ДО убийства потока занятого моей задачей? Что делает IIS с накопившимися в ThreadPool-е заданиями — просто теряет их?
IIS будет ждать только те потоки, которые обрабатывают запросы. Про ваши собственные он нничего не знает. Поэтому Нужно сообщить ему об этом посредством
этого.
Когда вызовется метод Stop, вам надо задержать исполнение, пока не завершится ваше задание.
http://msdn.microsoft.com/en-us/library/system.web.hosting.iregisteredobject.stop
Здравствуйте, dmitry_npi, Вы писали:
_>Здравствуйте, Glenn, Вы писали:
G>>У меня есть ASP.NET приложение работающее на IIS 6. Иногда (нечасто) у него будет необходимость запустить 'длинную' (до 3 мин) задачу — запись пачки данных в БД. Я знаю что такие вещи положено выносить из ASP-приложения вовне — например в сервис. Тем не менее передо мной поставлена задача сделать это в рамках ASP-приложения. Для этого я планирую создать либо поток через "new Thread(...)", либо использовать ThreadPool ASP-приложения.
G>>Тем не менее я не знаю точно что случится если в момент когда моя 'длинная' задача будет работать, кто-то захочет остановить ASP.NET ApplicationPool (вручную или произойдёт периодический Recycling). Ну или весь IIS перезапустят.
G>>Что будет by default — IIS будет ждать пока моя задача не завершится? Или он будет ждать только некоторое время а потом просто убьет мой поток? Как мне правильно обрабатывать такую ситуацию? Application_End вызовется ДО убийства потока занятого моей задачей? Что делает IIS с накопившимися в ThreadPool-е заданиями — просто теряет их?
_>IIS будет ждать только те потоки, которые обрабатывают запросы. Про ваши собственные он нничего не знает. Поэтому Нужно сообщить ему об этом посредством этого.
_>Когда вызовется метод Stop, вам надо задержать исполнение, пока не завершится ваше задание. http://msdn.microsoft.com/en-us/library/system.web.hosting.iregisteredobject.stop
Да, спасибо. Я это ужё нашёл.
Сейчас мепя больше интересут вот какой вопрос : какой вариант выбрать из 'Для этого я планирую создать либо поток через "new Thread(...)", либо использовать ThreadPool ASP-приложения.'
Сначала я думал использовать ThreadPool ASP-приложения. Я считал что ЧАСТЬ его используется для HTTP handlers, остальное — для всех остальных; и что таким образом мои 'длинные задачи' не будут мешать HTTP handler-ам.
Но я провёл эксперимент на IIS 7 и увидел: после того как я создал 50 своих задач через ThreadPool.QueueUserWorkItem, НИ ОДИН HTTP request не может пробиться через них и быть назначенным на поток. Проще говоря, весь Web — интерфейс замрёт пока хоть одна моя длинная задача не закончится.
Использование "new Thread(...)" решает эту проблему — мои задачи не будут блокировать HTTP request-ы, не давая им пробиться на выполнение. Но есть другая проблема — если таких "new Thread(...)" будет создано достаточно много, уже Windows в целом (не только моё web app) начнёт от этого 'задыхаться'.
Решить эту проблему можно было бы используя для моих длинных задач тоже Thread Pool, отдельный от ASP.NET ThreadPool. Но .NET не даёт возможности создавать несколько Thread Pool-ов внутри одного AppDomain; а писать самому как-то не хочется
Честно говоря, познаний не хватает дальше... Но — ThreadPool вообще предназначен для коротких задач, в этом его смысл — выполнить задачу и взять другую.
И к тому же вы пишете
Иногда (нечасто) у него будет необходимость запустить 'длинную' (до 3 мин) задачу
Поэтому я думаю, что лучше все-таки через "new Thread(...)". Когда же исчерпаются системные ресурсы — ну что ж, значит, они кончились. А выбор между отдельными потоками и ThreadPool я бы производил по соотношению между продолжительностью задачи и частотой поступления задач. Часто поступают короткие задачи — ThreadPool. Редко поступают длинные — новые потоки.
