В связи с попытками использовать AppScheduler для запуска процессов по расписанию возник вопрос стабильности и устойчивости.
Неясно как поведет себя созданное с помощью AppScheduler.Instance.ScheduleJob(job, trigger) задание при нештатных ситуациях. Задание согласно триггеру должно выполняться бесконечно с неким интервалом времени.
Делаем страшное - перезагружаем сайт в IIS (можно еще страшнее - перезагрузить IIS или перезагрузить сервер целиком). Что будет с работой задания? Оно само поднимется или надо "помочь"?
Вопросы публикую, так как сам пока не нашел закономерности и точного ответа. У меня после перезапуска сайта джоб ожил, но только после того, как я запустил клиентское приложение - зашел в BPM. Может быть это совпадение?
Нравится
"The problem with IIS is the application pool that gets recycled and won't start serving before the first web request that will wake it from sleeping state. Thus it's quite impossible for Spring.NET/Quartz.NET to take actions as the process isn't running and there's no way to keep the process running programmatically."
Похоже проблема есть...
И с решением будет сложно :cry:
Наблюдение на данный момент такое.
Есть уже описанный джоб. Запущен клиент. Делаем "больно" сайту, перезапускаем его. Клиент остается живым, джоб погибает и признаков жизни не подает. Реанимировать его пока сумел только повторным запуском клиента (т.е. выходим и заходим на уже перезапущенный сайт - видим что джоб спокойно начинает работу).
Кстати, какая версия IIS используется на хостинге bpmonline - IIS 7.5?
Под нее есть "разогрев", официальный плагин, который имитирует request от реального приложения, тем самым ускоряя последующую работу приложения и решая проблему продолжения работы джоба. В версию IIS8.0 данное расширение уже встроено...
Александр, добрый день.
Попробуйте использовать этот плагин.
"Олейник Дмитрий" написал:Попробуйте использовать этот плагин.
На iis 7.5 не дало ожидаемого результата. Возможно, что-то делал неправильно.
Последнее наблюдение - quartz возобновляет свою работу, если после перезагрузки сайта просто перезайти на главную страницу сайта, даже без авторизации.
Новости с полей :)
"Разогрев" результатов не дал.
Если поменять для пула "Режим управляемого контейнера" на "Классический", то quartz job прекрасно переживает перезапуск сайта. После перезапуска сервера понятное дело погибает (точнее переходит в какой-то хитрый режим ожидания) и работать начинает только после попытки загрузить заново страницу авторизации.
Поэтому в принципе пока эксперименты в данном направлении заканчиваю, они похоже будут безрезультатными. Scheduler в рамках IIS это тупиковое направление. Надо придумывать что-то другое.
Чем чреват классический режим пула в контексте BPMOnline, кстати (в рамках расширения кругозора)?
И еще есть вопрос: как обстоят дела с использованием cron-подобного планировщика на хостинге, где размещен bpmonline? Возможности такой нет?
Александр, постараюсь "завлечь" в ветку разработчиков для предоставления комментариев.
"Олейник Дмитрий" написал:Александр, постараюсь "завлечь" в ветку разработчиков для предоставления комментариев.
Видимо завлечь разработчиков не так то просто :smile:
Скучно им тут...
Александр, приветствую!
"Александр Кудряшов" написал:"Разогрев" результатов не дал.
- Здесь нужно смотреть, что именно за приложение вы прогревали: WebApp или WebApp.Loader
Как вы уже отметили, процессы начинают запускаться, как только зайти на страницу авторизации. Это связано с тем, что страница относится к приложению WebApp.Loader, в котором и хостится инстанс Scheduler'а, выполняющий задания.
Фактически, "кустарный прогрев" можно настроить, заставив любое клиентское приложение вызывать регулярно (например, раз в 10 мин.) url страницы авторизации или Auth-сервис.
Таким образом можно решить задачу с условным названием Задания с высоким уровнем требований к регулярному запуску
Что касается процессов, которые после запуска будут независимы от IIS и, соответственно, устойчивы к перезапуску сайта - их выполнение придется реализовывать в контексте отдельного приложения.
Варианты (продумал на лету, пока детально проблем не распишу):
1. можно запускать по планировщику exe-файл, в котором выполнять логику задания;
2. организовать windows-сервис, который будет осуществлять хостинг кода заданий и иметь некий API для их старта;
3. Отдельный сайт, с отличным от основного приложения Application пулом - для него IIS, соответственно, будет запускать отдельный W3WP процесс
Михаил, спасибо за ответ!
Пока по данной теме однозначного решения не нашел...
Наблюдение следующее: если для пула приложений выбрать "Режим управляемого конвейера" "Встроенный", то после перезапуска сайта джобы работу не продолжают. Если выставить "Классический" - то джобы работают даже после перезапуска сайта. Это радует, однако есть вопрос - есть ли принципиальная разница именно для BPMOnline 5x какой пул использовать?
Реально ли решить вопрос с использованием на хостинге bpmonline.com с использованием "классического" режима?
Это хотя бы решает половину проблемы ;)
Александр, этот режим не проверялся и не тестировался. Не известно как он может повлиять на работу других модулей. Поэтому его использование не желательно.
"Олейник Дмитрий" написал:Александр, этот режим не проверялся и не тестировался. Не известно как он может повлиять на работу других модулей. Поэтому его использование не желательно.
Понятно... Дмитрий, спасибо за ответ.