Комментарии 7
Лучше сделать бин с Executor на несколько потоков, тогда скедулер будет использовать его и будет сохраняться интервал между завершением таски и началом новой.
На сколько помню, при использовании Async, интервал получается между началом старой и началом новой.
если использовать 1 пул потоков он рано или поздно забьется и приведет к очень неприятному поведению, когда таски не выполнятся/выполнятся поздно. Обычно создаю пул из 1 потока шедулера. Если используются шедулеры.
Можно и как в статье, регистрируя пулы и прописывая в @Async, но это много бойлерплейта. Если единственная задача пула обработать задачу по расписанию - нет смысла плодить 5 строк в разных классах вместо 1й
Пришел к выводу, что стандартный Timer использовать в большинстве случаев проще + не возникает эта не очевидная проблема с выполнением расписания в одном потоке/пуле.
Как-то оно всё неочевидно и выглядит не очень надёжным. Кто его знает - треды кончатся у приложения и джобы перестанут отрабатывать, а мы об этом даже не узнаем (только из логов разве что, т.е. по их отсутствию).
Для MVP-приложения сойдёт, но для прода, пожалуй, продолжу делать на Quartz. Как-то понадёжнее ИМХО.
Кварц находится на первом месте в моём топе худших либ для джава. Я вообще не понимаю тех людей которые используют её вместо Spring Schedule.
Кварц - это образец оверинженеринга, дикий блакбокс с нулевой кастомизацией, который гадит в БД и делает затруднительным отладку и траблшутинг.
Кто-то говорит что null - это ошибка на миллиард долларов, но на самом это место занимает quartz
Спасибо, что делишься знаниями.
А если бы два метода, помеченные @Scheduled находились бы в разных классах, была бы проблема, что вторая джоба не стартует пока не выполнится первая? Обработчик шедулеров один на приложение или один на класс?
И ещё, если микросервисы + шедлок, то видимо проблема не так актуальна, поток из другой поды сервиса отработает.
@Scheduled + @Async (в Spring Boot)