Quartz job does not fire, often

0
votes

I'm using quartz 2.2.1 and Spring 3.2.5, both in a Maven / war project.

My war-file deploys fine under apache-tomcat-7.x, and the logs indicate that all of the quartz jobs are loaded. Here's where the trouble begins.

Several jobs fire as determined by their triggers. But consistently, in many instances, the trigger does not fire the job when it should, and other times does fire the job as expected. Why?

It's as if quartz has a bug interpreting triggers -- especially when triggers result in multiple jobs at a single time-slice. (Eg, on each 10th minute of the hour, 3 different jobs should fire).

Can anybody explain what's going on? To my thinking, there should not be any missed triggers at all.

Thanks.

1
quartz-scheduler
My trigger is a cron trigger defined in jobs.xml setup. I rely on the default or "smart-policy" for how to respond to trigger misfires -- see Quartz docs for more information (Eg, quartz-scheduler.org/generated/2.2.2/html/qtz-all/#page/…). In my case, that means MISFIRE_INSTRUCTION_FIRE_NOW. quartz.properties specifies org.quartz.threadPool.threadCount=10. I believe my job is being starved out of processor cycles. - Kode Charlie
Hi, did you manage to solve your issue? Me and my team are kind of having the same problem but we could not find any clues to what makes the trigger not firing the job when it should. Thank you! - TBogdan
No, I do not have a definitive explanation of what's going on. My own opinion at this point is that Quartz is actually buggy in numerous, irksome ways. I am trying to move as much of our Quartz-related logic into separate, independent processes in hopes of avoiding the Quartz bugs and hopefully achieving higher run-rates for my processes. Good luck. - Kode Charlie
Thank you for your response. We managed to solve our issue changing the misfire treshold, we had 10 miliseconds and it was too little. Now we changed our config and everything works fine. New config part that works: <add key="quartz.jobStore.misfireThreshold" value="10000" /> - TBogdan

1 Answers

0
votes

For this particular issue, changing the misfireTreshold to a bigger value, solves the issue. We had 10 milisecond configured, changing it's value to 10000 solved the issue. 

<add key="quartz.jobStore.misfireThreshold" value="10000" />