|
|
|
Patch that does the simplest part of the my suggestion. Untested though - I imagine visual inspection would be used as the test.
Something like that happens for me as well.. (version 1.6.0)
java.lang.NullPointerException at org.quartz.simpl.RAMJobStore.applyMisfire(RAMJobStore.java:1141) at org.quartz.simpl.RAMJobStore.resumeTrigger(RAMJobStore.java:1000) at org.quartz.simpl.RAMJobStore.resumeJobGroup(RAMJobStore.java:1077) at org.quartz.core.QuartzScheduler.resumeJobGroup(QuartzScheduler.java:1149) at org.quartz.impl.StdScheduler.resumeJobGroup(StdScheduler.java:461) .... The Quartz code goes like.. java.util.Date tnft = tw.trigger.getNextFireTime(); if (tnft.getTime() > misfireTime) { return false; } And tnft is suddenly null. It does not happen always though. I could not determine the exact circumstances when it becomes null. The trigger is a SimpleTrigger. I've tried different misfire settings without any result. I'm experiencing the same issue as the last commenter. In my particular case, I'm trying to resume a trigger that has no next fire time. applyMisfire() should check to ensure tnft is not null before trying to use it.
The latter two comments appear to be a different issue to this one.
Re-reading the first one, I suspect the aim was for the 'continue' to iterate the loop a second time, letting the calendar get set then. Unfortunately continue doesn't skip the while clause in a do-while so as the reporter points out, this is a single-iteration loop. A second attempt at a patch - this time I've rewritten the method to be simpler while (I think) retaining the originally intended logic. Eyeballs welcome.
I've created a new issue based on the two NPE comments:
svn ci -m "Applying second patch from
Sending src/java/org/quartz/SimpleTrigger.java Transmitting file data . Committed revision 720. svn ci -m "Applying second patch from Sending src/java/org/quartz/SimpleTrigger.java Transmitting file data . Committed revision 721. The original remark said:
"CronTrigger" and "SimpleTrigger" but it only seems to be fixed in the SimpleTrigger and not yet in the CronTrigger. Since the ticket is closed I can't attach a new patch. Furthermore the documentation of the misfireThreshold parameter in Trigger.java is a bit unclear about what the parameter means. That's why I was looking in the code of both example triggers. Linking the two issue's to each other. Created QUARTZ-678 since this ticked (557) was closed a long time ago while "only" 1/2 of the ticket was actually solved
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
That would be the 4th time this while loop appears in the file, so making it a private helper method seems tempting. Setting up a unit test for this seems non-trivial.