So you think you understand misfireThreshold?

One of the most critical and least documented features of Quartz is the concept of misfiring and how misfiring is handled. If a trigger was supposed to carry out a job a certain time, and for some reason it was not carried out at that time, it is a misfired trigger. But not any trigger could be treated as a misfired trigger. For e.g. if a trigger is long due for 2 hours from its actual firing time, does it make sense to treat that as a misfired trigger? To make that decision Quartz scheduler relies upon a configurable parameter called misfireThreshold. It is specified in milliseconds. Whenever a trigger is due for misfireThreshold or lesser amount of time, it will be treated as a misfired trigger and triggered depending on the misfire policy specified in the job detail.

For e.g. on a certain situation you might want a misfired trigger to be fired immediately, on a certain other situation you might decide its okay to reschdule the same trigger to the next firing time. For SimpleTrigger, there are five policies available and all of them are documented as a part of the API here. They are pretty much self explonatory.

It is critical to understand the default value of misfireThreshold is 30 seconds. As an example, consider you have a trigger that gets fired once in every 1 second to carry out a job that cannot be concurrently executed. The job usually takes less than a second to complete, but on a certain instance it takes around 20 seconds to complete. As soon as that job is complete, you will see that there are 19 times the same job was fired immediately! This is because, all the 19 times when the trigger must have fired qualify as misfired triggers by the default value of misfireThreshold.

One of the bad things that could happen when the above mentioned scenario happens is there are a large number of triggers that need to be carried out within a short interval of time. This might not be a desired thing, also it introduces starvation at times. I have observed that the misfired trigger gets executed repeatedly blocking the execution of other triggers!

My suggestion is to keep the misfireThreshold to be half of the repeat interval. Of course, it depends on your application too. But in general, this might be good enough. Remember that misfireThreshold is common acros all the triggers, where as the repeatInterval is for each trigger. So if you have various triggers with differing repeat intervals, decide what is the optimum value for your case.

One thing I am repeatedly assured about using Open Source Software is never think that the default configuration parameters are fit for most of the cases. Some of my situations have required tuning using often least documented or least understood parameters!


underdog said…
Hi Roy,

The quartz framework documentation says otherwise about the meaning of misfireThreshold property:
"The the number of milliseconds the scheduler will 'tolerate' a trigger to pass its next-fire-time by, before being considered "misfired". The default value (if you don't make an entry of this property in your configuration) is 60000 (60 seconds)."

write my essay said…
The possible objects and values would even help students regarding all those values which must have been followed by them for the better cause and success.
It has brought around more of the concerns and awareness among the students which by the time and meaning must have been followed by the individual.
Lester McGee said…
There has been every possible cause and opinion mentioned in detail and hopefully by the time would govern better grounds and essentials. Visit electronic products for electronic products

Popular posts from this blog

The mysterious ORA-03111 error

Note on allocationSize parameter of @SequenceGenerator while using JPA

Creating a Collection with a single element