If you're using Quartz Scheduler and CronTriggers, there's a reasonable chance that your Job's execution time might occasionally take longer than your Schedule Triggers.
What happens then?
Default behavior for Quartz Scheduler is to fire the subsequent Triggers even if the previous jobs haven't finished. The problem is that frequently that can cause unpredictable racing conditions and concurrency issues.
To fix that, Quartz offers two solutions:
Quartz 1.x: Make your jobs implement the StatefulJob interface
-
Both these solutions(StatefulJob has been deprecated on Quartz 2.x) will tell the scheduler that this Job class should only have one instance running at a time.
Again, another question comes up. What happens when a Trigger is fired and intercepted because there's an ongoing previous execution? That's when Misfire Instructions come in play. First, set a misfire threshold in the properties, which will tell the scheduler how long to wait before considering a job trigger as a misfire:
#This property decides how long does the scheduler waits before considering the sebsequent jobs as misfired (default is 60000 millis)
org.quartz.jobStore.misfireThreshold=60000
Second, when instantiating the job Trigger, we've an option for setting a Misfire Instruction to decide what to do on each case:
Choose the most appropriate setting for your trigger to ensure the expected behaviour. To conclude, a setup suggestion for blocking concurrent execution on a job:
-
Set the org.quartz.jobStore.misfireThreshold=1 so that a single millis of lateness declares the trigger as a misfire if there's a previous job ongoing
Set the trigger misfire instruction to MISFIRE_INSTRUCTION_DO_NOTHING. This will simply make it abort current execution and schedule itself for next trigger execution.
trigger.setMisfireInstruction(
CronTrigger.MISFIRE_INSTRUCTION_DO_NOTHING);
Sample Code:
https://github.com/eduardohl/quartz-boiler