SchedulerFactoryBean has race condition in Quartz cluster [SPR-1812] #6506
Comments
|
Juergen Hoeller commented Thanks for pointing this out in such clear detail, Jasper! You insider input is greatly appreciated :-) I've addressed these issues as you suggested, also re-registering JobDetails held by a JobDetailAwareTrigger. Juergen |
|
Jasper Rosenberg commented Glad I could be helpful. I've certainly taken advantage of the great Spring-Quartz integration on my own projects. I took a glance at the changes you made, and they look good to me. I did have one quick thought though, which was that the javadoc for the return value of addTriggerToScheduler() doesn't quite synch with the behavior of the method. It reads: I think it probably should read something along the lines of: I think that if I understood the intent correctly, you would also want to return false when the scheduleJob(trigger) fails and overwriteExistingJobs is false, something like: Of course, all this is technically moot right now since it is the ignored return value of a private method :) |
|
Christian Greene commented Juergen Hoeller, my team is also getting an error similar to this but while "rescheduling" the job's trigger. The catch-and-ignore put into The error causes the context to fail to load and thus the application fails to start. Can the Thanks, The stack trace:
|
|
Juergen Hoeller commented Christian Greene, since this is an old and closed ticket, please create a new JIRA issue for the rescheduling part. I'll address it ASAP for 5.0.9 and 4.3.19 then. |
|
Christian Greene commented
#21651 created |
Uh oh!
There was an error while loading. Please reload this page.
Jasper Rosenberg opened SPR-1812 and commented
If you try to have the SchedulerFactoryBean add the same Trigger in two Quartz clustered instances (and you are only adding Triggers), you can get a race condition in registerJobsAndTriggers() where both instances don't find the Trigger, and both then try to add it using scheduleJob. In this case, the last one in will fail with an org.quartz.ObjectAlreadyExistsException, which will keep the SchedulerFactoryBean from successfully starting.
There is discussion of this issue in the Quartz forums here: http://forums.opensymphony.com/thread.jspa?messageID=45028꿤
and here: http://forums.opensymphony.com/thread.jspa?messageID=45027꿣
There is a similar issue in the org.quartz.plugins.xml.JobInitializationPlugin as documented here:
http://jira.opensymphony.com/browse/QUARTZ-295
Spring is actually exposed to this QUARTZ-295 problem as well because registerJobsAndTriggers() can make use of ResourceJobSchedulingDataProcessor which extends the JobSchedulingDataProcessor. However, this can only manifest itself if the user didn't provide a transactionManager to the SchedulerFactoryBean.
Unfortunately, there is no great way to fix these problems right now without some enhancements to the Quartz interface.
My best suggestion for solving the first problem right now is to catch the ObjectAlreadyExistsException thrown by this.scheduler.scheduleJob(trigger) and either
a. Simply swallow the exception, possibly with a log message indicating that this is assumed to be due to a cluster race condition and can be safely ignored.
b. Try to rescheduleJob() the Trigger if overwriteExistingJobs is true.
There isn't much that can be done about the second problem other than perhaps emphasising in the javadoc that you should be passing in a transactionManager if you are using the jobSchedulingDataLocation(s) properties.
As an aside, it is a little unclear to me why, if a Trigger is not new, but is a JobDetailAwareTrigger, SchedulerFactoryBean does not try to replace the Trigger's JobDetail. I'm not sure the current behavior would be expected, and I think it would be easy to assume the opposite based on the current SchedulerFactoryBean javadoc.
Affects: 1.2.7, 2.0 M3
Issue Links:
The text was updated successfully, but these errors were encountered: