Здравствуйте. Хочу поделиться с вами знаниями добытыми кровью и слезами. Рожденные страданиями и отполированные отчаянием, пусть их блеск сияет в вашем сознании так же ярко, как мои седые волосы после всех испытаний. Вся мудрость монахов Тибета меркнет перед светом озарения, который вы постигнете.



OnAppEnd из AppEventListenerBase на Windows 7.17.4 работает, а на Net.Core 7.17.4 НЕ РАБОТАЕТ (или там нету UserConnection, что в принципе не позволит вам сделать какую-либо операцию на уровне приложения). Вы никаким образом не сможете дать выполняющимся потокам информацию о том что приложение хочет остановиться. И пока ваши потоки выполняются - рестарта не произойдет! Если у вас длинная операция или рекурсивная логика (как было в моем случае) - вы будете ждать вечность пока что-то не остановит ваш(и) поток(и). Вы думаете вы хитрее и разнесете выполнение логики в отдельные треды? А вот и нет: приложение просто рухнет на рестарте! Видимо это связано с тем, что в контейнере оказывается две работающие сборки. Решение кстати в таком случае - перезапуск контейнера. Но мы же не можем при каждой поставке перезапускать контейнеры у заказчика, верно?



Так что же делать, спросите вы? Как нам быть, Егор? Что делать, если OnAppEnd не работает?

С этим вопросом я странствовал по миру и много думал. За время поисков я разгадал загадки Атлантиды, Бермудского треугольника, убийство Кеннеди и Тунгусского метеорита, но загадка рестарта приложения Creatio 7.17.4 на Net.Core не поддавалась решению. Приложение то не перезапускалось, то падало при рестарте. Долго ходил я в поисках ответа, пока случайно не заметил, что при рестарте приложения Quartz перестает запускать ежеминутные триггеры.



Во время попытки рестарта приложения планировщик заданий переходит в режим паузы (StandBy), определить это легко через класс AppScheduler: AppScheduler.Instance.InStandbyMode. Если true, то планировщик остановлен - это значит, что приложение пытается перезапуститься. Планировщик может останавливаться и по другим причинам, но эта - одна из них, которая может быть спасительной соломинкой в таких ситуациях.



Вы можете вставить проверку в логику вашего потока на AppScheduler.Instance.InStandbyMode == true и завершать его в этом случае. После завершения всех потоков приложение перезапустится.



Спасибо за внимание!

Нравится

Поделиться

1 комментарий

Кстати, на неткоре также есть особенность: запускаемые через FlowEngine процессы из EntityEventListener в фоновом режиме не будут идти по элементам (видимо также нету UserConnection). Приходится запускать их не в фоновом режиме.

Показать все комментарии

В связи с попытками использовать AppScheduler для запуска процессов по расписанию возник вопрос стабильности и устойчивости.
Неясно как поведет себя созданное с помощью AppScheduler.Instance.ScheduleJob(job, trigger) задание при нештатных ситуациях. Задание согласно триггеру должно выполняться бесконечно с неким интервалом времени.
Делаем страшное - перезагружаем сайт в IIS (можно еще страшнее - перезагрузить IIS или перезагрузить сервер целиком). Что будет с работой задания? Оно само поднимется или надо "помочь"?
Вопросы публикую, так как сам пока не нашел закономерности и точного ответа. У меня после перезапуска сайта джоб ожил, но только после того, как я запустил клиентское приложение - зашел в BPM. Может быть это совпадение?

Нравится

10 комментариев

"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 с использованием "классического" режима?
Это хотя бы решает половину проблемы ;)

Александр, этот режим не проверялся и не тестировался. Не известно как он может повлиять на работу других модулей. Поэтому его использование не желательно.

"Олейник Дмитрий" написал:Александр, этот режим не проверялся и не тестировался. Не известно как он может повлиять на работу других модулей. Поэтому его использование не желательно.

Понятно... Дмитрий, спасибо за ответ.

Показать все комментарии