History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QUARTZ-293
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: James House
Reporter: Stephen Crowley
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Quartz Scheduler

JobStore.shutdown called before releaseAcquiredTrigger()

Created: 03/Nov/05 09:00 PM   Updated: 24/Dec/07 01:29 AM
Component/s: Core, Job Stores
Affects Version/s: 1.5.1
Fix Version/s: 1.6

Flags: Important


 Description  « Hide
i've implemented my own JobStore using sleepycat java edition as a backend.

if I schedule a job and then shutdown..

JobStore.shutdown() is called befoe JobStore.releaseAcquiredtrigger() thus causing my backing database to close and the subsequency releaseAcquiredtrigger() call fails.

shutdown() should be the very last thing that happends

As a work-around im making releaseAcquiredtrigger() re-open, release and then shutdown again.


 All   Comments   Change History      Sort Order:
Jasper Rosenberg - [28/Mar/06 03:36 PM ]
I think the current behavior is probably correct.

If you want all of your currently firing triggers to complete before shutdown completes, you should call Scheduler.shutdown(true) (waitForJobsToComplete).

Otherwise, the assumption is that you want a hard shutdown of Quartz, and if you want special behavior in this case you can set the recovery flag on your JobDetails and handle each case as defined by your application's need.

Zach Vonler - [22/May/06 02:10 PM ]
I am now seeing this behavior in my application, and believe that it is the result of a race condition. In my case, I am calling shutdown with waitForJobsToComplete=true, but am occasionally seeing a call to releaseAcquiredTrigger on a job store that has been shutdown.

What I think is happening is that the shutdown method of QuartzScheduler is considering QuartzSchedulerThread to have stopped running after the call to QuartzSchedulerThread.halt(). However, it can be the case that at the time halt() is called, the QuartzSchedulerThread is actually sleeping at line 273. If QuartzScheduler is able to call resource.getJobStore().shutdown() before that sleep completes, then the QuartzSchedulerThread can end up calling releaseAcquiredTrigger on a shut down job store, which does not seem correct.

I think the proper fix is to change QuartzSchedulerThread.halt() to return only once the thread has actually stopped executing, or else have QuartzScheduler check for Thread.isAlive() to return false before continuing.

Jasper Rosenberg - [22/May/06 02:49 PM ]
Thanks for finding this case Zach!

What I am leaning towards is having the QuartzScheduler call join() on the QuartzSchedulerThread after the call to halt so shutdown() won't continue until the QuartzSchedulerThread is dead. (this would basically be the same as your "check for Thread.isAlive() to return false before continuing" suggestion)

try {
            schedThread.join();
        } catch (InterruptedException ignore) {
        }

Jasper Rosenberg - [22/May/06 03:18 PM ]
I added the join as described above.

I went back and forth on whether to pass a timeout to join() and ultimately decided against it since, if it required a timeout, it would imply a bug in the QuartzSchedulerThread, and I'd rather not risk masking such a bug if it were to exist.