[
https://issues.apache.org/jira/browse/OPENEJB-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599829#comment-13599829
]
Andy Gumbrecht commented on OPENEJB-2004:
-----------------------------------------
It can, but that just masks the issue in
org.apache.openejb.core.timer.EjbTimerServiceImpl#shutdown
There is the first 'friendly' shutdown thread which waits for the latch in
'public void schedulerShutdown()'. This now does not get called, and I am not
sure why. I've started to look at the quartz source, but it has something to do
with the jobs not being unscheduled as they were before.
The timeout is then reached and the second stop thread calls s.shutdown(false);
which in effect kills quartz.
If I can't work out why the the s.shutdown(true) hangs then I'll just bin the
first thread and let quartz get on with it. This will mean InterruptableJob
implementations will not get interupted.
> EjbTimerService fails to shut down after recent changes
> -------------------------------------------------------
>
> Key: OPENEJB-2004
> URL: https://issues.apache.org/jira/browse/OPENEJB-2004
> Project: OpenEJB
> Issue Type: Bug
> Components: container system
> Affects Versions: (trunk/tomee)
> Environment: NA
> Reporter: Andy Gumbrecht
>
> EjbTimerService fails to shut down after recent changes made for persistent
> timers.
> The pausing of jobs rather than un-scheduling seems to block the first
> 'friendly' shutdown thread, causing the thread to wait for the defined
> timeout.
> This occurs synchronously, so multiple scheduler shut down calls can take an
> age to complete.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
