Здравствуйте, Александр!

Если у Вас on-demand, то следующий абзац можно упустить.
Для того, чтобы процессы постоянно, а главное вовремя, запускались, должны быть выполнены два условия:
1) Пул приложения должен быть запущен
2) Сайт должен работать

Чтобы выполнялось первое условие, установите таймаут простоя IIS равным 0:

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

Процессы имеют те же права, что и пользователи, под которыми они запущены. В зависимости от целей, Вам выбирать от чьего имени запускать процесс.
Например, процесс интеграции с чем либо логично было бы запускать под пользователем, обладающим правами системного администратора.
Процессы по созданию задач подчиненным лучше все же запускать под именем руководителя (автором задачи будет руководитель):).

Алексей, вроде бы получилось, спасибо!
Полностью проверить удастся завтра.
Также, если кому-то пригодится, smarterPing нужно устанавливать через имеющийся bat-файл из командной строки,запущенной от имени администратора.

Здравствуйте.
Если у Вас On-Site, тогда необходимо установить для пула приложений IIS, на котором работает приложение, Idle Timeout = 0
Настроить автоматический мониторинг Loader'a и приложения, ниже варианты:
С помощью бесплатного сервиса мониторинга https://uptimerobot.com/ настроить автоматический мониторинг c периодичностью 5-10 минут - наиболее быстрый путь.
С помощью автоматического запуска скрипта мониторинга приложения. Шаблон скрипта PowerShell в приложении Ping.ps1, в нем необходимо изменить адрес приложения. После этого, нужно запланировать выполнение этого скрипта через планировщик Windows c периодичностью 5-10 минут. Автоматический запуск можно настроить по инструкции http://windowsnotes.ru/powershell-2/zapusk-powershell-skripta-po-raspis….
Настроить автоматический запуск SQL-скрипта очистки \ перезапуска зависших заданий, скрипт в приложении ResetErrorQuartzTriggers.sql - с периодичностью 30 минут
Настроить автоматический запуск задания MSSQL, выполняющего этот скрипт - наиболее простой способ.

Спасибо за подсказку!
Настроил через Uptimerobot и SQLServer Job

Мне вот интересно, а в случае on-demand все эти процедуры по-умолчанию проведены для сайта клиента, и мониторинг настроен, и скрипты очистки/перезапуска заданий работают?

Здравствуйте.
В случае, когда сайт находится на On-Demand, мониторинг его доступности выполняется средствами, которые предоставляет компания, поддерживающая сервера.

Свежая ссылка на скрипт http://ftp.bpmonline.com/support/downloads/Other/ResetErrorQuartzTrigge…

Котенко Александр пишет:

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

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

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

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