Comments 25
public void Configuration(IAppBuilder app)
{
///....
ISchedulerFactory schedulerFactory = new StdSchedulerFactory();
IScheduler scheduler = schedulerFactory.GetScheduler();
app.UseCrystalQuartz(scheduler);
}
И все заработало — по ссылке /quartz открылась панель, которая показывает запущенные задачи.
Возможно я не понимаю как готовить Hangfire или Quartz, но ни один из них не позволяет нормальным образом организовать Circuit Breaker на случай аварий.
Hangfire не позволяет практически конфигурировать интервалы между попытками.
Есть Polly, который всё это умеет делать замечательно, но туда никак не вкрутишь адекватно персистентность, он не про это.
Hangfire не позволяет переопределять названия таблиц в БД, так что использовать придется отдельные БД на каждое приложение, либо разделять их по схеме (dbo и т.д.).
Quartz творит с БД какое-то непотребство, гора таблиц в 2000-like стиле.
В итоге — придется писать видимо свой инструмент.
Hangfire – отличное решение, но, вроде, сразу требует использования базы данных для хранения очереди задач. Да и не совсем там все бесплатно – есть и платная версия.
Вроде? Вы их не запускали, что ли, когда сравнивали?
Чтобы внести ясность: да, Hangfire-у для работы необходима БД на SQL Server. В этой базе хранится очередь, через нее же синхронизируются процессы, выполняющие задачи из очереди. Приятный бонус такого подхода — "из коробки" работает кластеризация, т.е. распараллеливание процесссов-обработчиков. В платной версии хранилищем задач может выступать Redis, и есть ряд синтаксических вкусностей (прекрасно обходились и без них). Код бесплатной версии открыт, и репозиторий уже становится популярнее Квартца, хотя Hangfire на много лет моложе.
Судя по документации
SQL Server and Redis support
Hangfire uses persistent storage to store jobs, queues and statistics and let them survive application restarts. The storage subsystem is abstracted enough to support both classic SQL Server and fast Redis.
SQL Server provides simplified installation together with usual maintenance plans.
Redis provides awesome speed, especially comparing to SQL Server, but requires additional knowledge.
поддержка Redis есть в бесплатной версии.
Судя по http://hangfire.io/pro/#hangfireproredis и состоянию пакета Hangfire.Redis — всё таки платно. Был бы рад ошибиться.
Ваша правда. Забыл, что к Hangfire все-таки можно прикрутить in-memory storage.
Я нашел Hangfire.MemoryStorage.
Но в описании сказано, что использовать можно только для тестирования. А дальше: "… не может использоваться в production ..."
It can be useful for testing purpose like check the behaviour and use it in a development environment. Please note that it should not be used in production (no integrity and no thread safe even if many cases are managed).
Этот пакет я и имел ввиду. Возможно, raptor знает что-то еще?
Да и в соседней ветке комментариев подсказывают про Hangfire.Redis.StackExchange.
Кинул актору задачу и не переживаешь что он завалится. CircuitBreaker, BackoffStrategy, Supervising из коробки.
Ну и до кучи персистентность, ремоутинг, кластеринг, и тут Остапа понесло…
Немного привыкнув к Scala код можно передирать почти 1:1, т.к. фреймворк полностью портирован.
Нужно сделать актора, который реагирует на команды. Изменение состояния происходит через генерацию и сохранении событий в хранилище. При восстановлении состояния читается поток событий и проигрывается заново реакция на них.
Персистентность руками делать не надо, просто подключаем плагин из готовых и работаем.
Если надо по-быстрому, то есть плагин для embedded SqLite.
Когда я "последний раз" искал что-то для фоновых заданий — брать большие комплексы типа Hangfire не хотелось из-за требования БД, а изощренные (извращенные) расписания для запуска типа "каждый понедельник в 8 утра, во вторник каждые 10 минут" с одной стороны были слишком заумными и нереальными, с другой стороны сразу же возникают опасения "что если при 10 минутном запуске задача будет выполнять 12 минут — запустится ли вторая не дожидаясь конца первой".
В итоге сделал свой велосипед RecurrentTasks — обычный Task просыпается, делает что надо и снова засыпает на заданный интервал. При этом для "сложных" задач, которые должны работать лишь "трижды в день" — все равно где-то в бизнес-требованиях есть "дата последнего запуска" той или иной функции — в итоге удобно оказалось сделать что таск стартует раз в 20-30 минут, считывает дату из реальной базы и "делает дело" только если надо. Заодно этим решается проблема "если приложение было выключено в заданное время" — при следующем запуске все отработает. Периодом можно управлять прямо внутри основного метод: если очередь пустая то следующий раз читать ее "через минуту", если еще что-то есть — "через 10 секунд".
Как запустить фоновый процесс в Asp.net