Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hello,

We are using Quartz to manage a bunch of stateless jobs that are all part of a single scheduler using Simple triggers that execute once. We have Quartz configured with a MySQL job store, to persist our queue, and aid in recovery if the scheduler is shutdown. We are using SimpleTrigger.MISFIRE_INSTRUCTION_FIRE_NOW as our misfire instruction.

For testing, we have our scheduler setup with only one thread. If we submit a bunch of jobs to the scheduler, with ascending start times, it starts executing them in order, as expected. But if we stop the scheduler and restart it (abruptly stopping the JVM and restarting the JVM), I expect that the scheduler would restart the the job that was running at the time the scheduler was shut down. Instead, the scheduler starts the next queued job that was previously submitted, and at some point in the future, the mis-fired jobs will execute again.

Ultimately, all of the jobs will execute, but not in the order I'd like, and and not in the order the jobs were originally scheduled for, based on start times.

Is there some configuration change I can make so the scheduler will always try to kick off mis-fired jobs before it tries to start new jobs?

Thanks in advance!
-Dave

Are you setting the request recovery flag on the JobDetails ?

Thanks for the reply. Yes, I'm setting the request recovery flag on the JobDetails.

I played around with it some more, and read through the source code, and it looks like I mis-interpreted the meaning of the "org.quartz.jobStore.misfireThreshold" property. I had wrongly assumed that lower values were better, but it appears I need to set it to a high value to get the behavior I wanted. It appears that after the server restarted, all of the jobs were getting their next fire dates updated to new dates, since they were all considered misfires. By changing the misfireThreshold to an absurdly high value, this makes the scheduler re-run the interrupted jobs first, then resumes with the other jobs in the queue.

-Dave