quarkus: Quarkus quartz should not reschedule jobs on start
Describe the bug
Bug introduced by https://github.com/quarkusio/quarkus/issues/20538
Anytime quarkus starts it will reschedule jobs, not matter if the job config changed or not. It’s a tough decision, at best it should only detect changes and WARN, nothing else. This can have serious collateral damages depending on what your jobs are doing.
If you are cleaning up your data once a year, you don’t want that to be re initialized and triggered every time you restart the app or scale up your cluster.
Expected behavior
Do not reschedule jobs, WARN or maybe improve the dev tools but this is too dangerous.
Actual behavior
All jobs are rescheduled on start.
How to Reproduce?
Pick any quartz based clustered app. Create a job running every 5 sec for example.
Request the db for select * from qrtz_simple_triggers and select * from qrtz_triggers
Restart the app and check the table again. All triggers, executions are reset, ignoring past execution and, most important, the expected and persistent next_fire_time on qrtz_triggers.
Output of uname -a or ver
no impact
Output of java -version
no impact
GraalVM version (if different from Java)
No response
Quarkus version or git rev
since 2.3.1
Build tool (ie. output of mvnw --version or gradlew --version)
no impact
Additional information
No response
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 17 (10 by maintainers)
Ya, sure it would be good for me too as I get to learn about quarkus more.
sorry for replying late, actually I was trying to fix my quarkus setup issues first before submitting my first pull request that’s why. can you check it out? #22717 Thanks 😃
@machi1990 I think that solution 1 makes sense. What other state is lost BTW?
@apat59 +1
Indeed the issue is only the lost of the persistent state, mainly the next fire time. Your solution looks perfect to me.
Not directly related but I’d also add this sort of warning in the guide: Whenever you change the @Scheduled.identity, remove the @Scheduled annotation, quarkus is not in charge of cleaning up the qrtz_ tables related rows, this must be handled by the migration scripts (flyway), or manually.
@coiouhkc btw https://github.com/quarkusio/quarkus/issues/14671#issuecomment-770180851 We hit the same concern as you really quickly, on version 1.11.
I don’t think it’s impossible to handle it but it really is a complex topic.
basically https://github.com/quarkusio/quarkus/pull/20546 should be reverted. Damages are done by
} else { scheduler.rescheduleJob(trigger.getKey(), trigger); LOGGER.debugf("Rescheduled business method %s with config %s", method.getMethodDescription(), scheduled); }As I said, it’s tricky. The root question being “how can we handle job config updates?” And even more complex “what if a developer changes the job id or simply removes the annotation?”
There is no solution, at some point the developer will have to update the quartz tables or implement his own job and trigger management service and perfectly know what he is doing and document his job inventory. I don’t see any safe way for quarkus to handle this auto-magically.