[#QUARTZ-543] updateAfterMisfire() not invoked by StdScheduler

Quartz Scheduler

updateAfterMisfire() not invoked by StdScheduler

Created: 07/Dec/06 10:17 AM Updated: 30/Apr/07 05:16 PM

Component/s:

Core

Affects Version/s:

1.6

Fix Version/s:

1.6.1

File Attachments:

Quartz543-repro.java (1 kb)

Environment:

RHEL

Issue Links:

Related

This issue relates to:
	~~QUARTZ-554~~ Trigger.getNextFireTime() returns dat...

Description

« Hide

I created a StdScheduler using the following method

StdSchedulerFactory schedFact = new StdSchedulerFactory();
mQScheduler = schedFact.getScheduler();
mQScheduler.scheduleJob(detail, trigger);

Where trigger is an instance of SimpleTrigger created with the following flag set

mTrigger.setMisfireInstruction(SimpleTrigger.MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_REMAINING_COUNT);

I paused a job whose configuration was to repeat after every 10 seconds, 10 times.

After two times execution of the Job, I fired a pauseJob() of the scheduler. After 30 seconds, I called the resumeJob();

As per the documentation, the execution which did not happen because the job was paused, will not be executed again and the job will be executed the REMAINING number of times.
Instead the job was executed 3 times in quick succession behaving in the way described for MISFIRE_INSTRUCTION_RESCHEDULE_NOW_WITH_REMAINING_REPEAT_COUNT

However, when I explicitly called updateAfterMisfire of the trigger after resuming the job, things worked as expected.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Henri Yandell - [14/Jan/07 08:48 PM ]

Simple Java file reproducing the symptom described.

Unlike Ritesh's report, calling updateAfterMisfire does not make the code work for me. Probably my reproduction is faulty.

[ Permlink | « Hide ]

Henri Yandell - [05/Feb/07 05:15 PM ]

Interestingly, the attached code works fine within Eclipse and has no problems. It's only on the command line that I can replicate Ritesh's report.

Weird.

[ Permlink | « Hide ]

Henri Yandell - [05/Feb/07 05:24 PM ]

Pay no attention to the idiot developer :)

My proposed fix for ~~QUARTZ-554~~ fixes this bug and it was still sitting in the workspace.

[ Permlink | « Hide ]

Henri Yandell - [30/Apr/07 04:42 PM ]

From James' email on discussion of ~~QUARTZ-554~~

***************************************************************************
With respect to ~~QUARTZ-543~~, I suspect the problem isn't that
updateAfterMisfire() isn't being called. The problem is that the
misfire threshold of the scheduler is set to a minute or more, and the
job/trigger is only paused for 30 seconds. Hence, when it is unpaused,
it has not misfired, and it eagerly begins to catch up (it has three
firings that rapidly catch up, per the description of the reporter).
This one should be closed as "not a problem" - unless someone can
actually show that if you leave the trigger paused for longer than the
misfire threshold, the misfire handling isn't done correctly. The
reason the patch for ~~QUARTZ-554~~ "fixes" this non problem is that it
actually breaks it - as soon as the trigger is unpaused, it updates the
next fire time to the current time, skipping a couple of the scheduled
fire times, breaking the semantics of the scheduler.
***************************************************************************

[ Permlink | « Hide ]

Henri Yandell - [30/Apr/07 05:16 PM ]

I changed the misfireThreshold to be 10000 instead of the default 60000 as James suggests and it behaves correctly.

[ org.quartz.jobStore.misfireThreshold = 10000 ]

Namely, there are not three quick triggers, and there are 6 remaining triggers (ie: 3 of the 11 are lost while it is sleeping for 30 seconds).