Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NPE thrown when acquiring next trigger due to null next fire time value #189

Closed
Dwisf opened this issue Oct 17, 2017 · 4 comments
Closed

NPE thrown when acquiring next trigger due to null next fire time value #189

Dwisf opened this issue Oct 17, 2017 · 4 comments

Comments

@Dwisf
Copy link

Dwisf commented Oct 17, 2017

During a soak testing of our application using Quartz (version 2.2.3), we notice the following exceptions being thrown from time to time:

org.quartz.core.ErrorLogger ERROR --- An error occurred while scanning for the next triggers to fire. 
java.lang.NullPointerException: null
	at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSupport.java:2837)
	... 5 common frames omitted
Wrapped by: org.quartz.JobPersistenceException: Couldn't acquire next trigger: null
	at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSupport.java:2864)
	at org.quartz.impl.jdbcjobstore.JobStoreSupport$40.execute(JobStoreSupport.java:2759)
	at org.quartz.impl.jdbcjobstore.JobStoreSupport$40.execute(JobStoreSupport.java:2757)
	at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3803)
	at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTriggers(JobStoreSupport.java:2756)
	at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:272)

Line 2837 of JobStoreSupport.java corresponds to the following code:

...
if (nextTrigger.getNextFireTime().getTime() > batchEnd) {
...

That is getNextFireTime() is null. The API for this method states ...If the trigger will not fire again, null will be returned. It looks like this code needs to check if getNextFireTime() is null before doing a getTime().

Is this a correct assessment?
@bsiamionau
Copy link

Any progress on this?

@sudhanmoghe
Copy link

We are also getting this error.
We started getting this error after adding 2nd node to cluster. We never got this error with single node.
We see the exception stack trace in logs. 285 in last one month. But, no issue in actual job execution. No failed or pending job.
We only have CRON jobs or Simple JOBS. I don't see any NEXT_FIRE_TIME < 0 in TRIGGERS table. Not sure what is causing the NPE and how to fix that.
We are running cluster with this config.
org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.oracle.OracleDelegate
org.quartz.jobStore.isClustered=true

Hope these details help in fixing the issue. Let me know if you need more details or want me to try out some thing.

@sudhanmoghe
Copy link

Found one more bug report with possible solution. #174
I have updated my config with
org.quartz.jobStore.acquireTriggersWithinLock=true.
Will update in weeks time to confirm whether that solved the problem.

zemian added a commit to zemian/quartz that referenced this issue Feb 15, 2019
@zemian
quartz-scheduler#189 improv: NPE thrown when acquiring next trigger d…
801abe0 
…ue to null next fire time value
@zemian zemian added improvement and removed bug labels Feb 15, 2019
@zemian zemian mentioned this issue Feb 15, 2019
Merged
@zemian
Copy link
Contributor

zemian commented Feb 15, 2019

I have put in a PR for this #361

However I should point out that this is not so much as bug than improvement to the code. Per design, there should not be any trigger store in DB with nextFireTime that will return null. If it does, it should already been remove from DB. If we do see this case, there is something wrong with the Trigger implementation of some kind of bad data with this trigger. There is no way to recover from this since it's unexpected. So as code improvement, we log a WARNING. Users should investigate why their trigger is in this state, and manually clean up the data in DB. Please do report new issue if you continue to see this.

@zemian zemian closed this as completed Feb 15, 2019
@zemian zemian mentioned this issue Feb 15, 2019
Merged
zemian added a commit that referenced this issue Feb 15, 2019
@zemian
Merge pull request #362 from zemian/issue-189-npe-acquire-triggers-ma…
128a4c3 
…ster

NPE thrown when acquiring next trigger due to null next fire time value #189
zemian added a commit that referenced this issue Feb 15, 2019
@zemian
Merge pull request #361 from zemian/issue-189-npe-acquire-triggers
f82405b 
2.3.x #189 improv: NPE thrown when acquiring next trigger due to null next fire time value
@zemian zemian mentioned this issue Feb 17, 2019
Closed
@Munich81 Munich81 mentioned this issue Apr 27, 2020
Closed
This was referenced Mar 8, 2021
Open
Merged
Open
Closed
This was referenced Mar 16, 2021
Open
Open
Munich81 added a commit to Munich81/quartz that referenced this issue Aug 4, 2021
@Munich81
quartz-scheduler#580 fix wrong warning from quartz-scheduler#189 change
e8594e9 
Warning regularly appears due to race condition on multi-instance environments
although nothing is wrong
Munich81 added a commit to Munich81/quartz that referenced this issue Aug 4, 2021
@Munich81
quartz-scheduler#580 fix wrong warning from quartz-scheduler#189 change
c26d74c 
Warning regularly appears due to race condition on multi-instance environments
although nothing is wrong

Signed-off-by: Munich81 <[email protected]>
Munich81 added a commit to Munich81/quartz that referenced this issue Aug 7, 2021
@Munich81
quartz-scheduler#580 fix wrong warning from quartz-scheduler#189 change
5951780 
Warning regularly appears due to race condition in multi-instance
environments although nothing is wrong
Munich81 added a commit to Munich81/quartz that referenced this issue Aug 10, 2021
@Munich81
quartz-scheduler#580 fix wrong warning from quartz-scheduler#189 change
09f5fa9 
Warning regularly appears due to race condition in multi-instance
environments although nothing is wrong

Signed-off-by: Munich81 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@bsiamionau @Dwisf @zemian @sudhanmoghe