forgot to mention: org.quartz.plugin.shutdownhook.cleanShutdown (see http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigPlugins )
this last one should be enough *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/8/19 Romain Manni-Bucau <[email protected]> > Hi, > > nice to hear you can now go further :) > > well some note about your issue: > 1) if you can share with us a thread dump (jps to get your java process id > + jstack <id> to get the stack ;)) it can help a lot > 2) did you specify the > properties org.quartz.scheduler.makeSchedulerThreadDaemon and > org.quartz.threadPool.makeThreadsDaemons > (the last one is relevant if you specify org.quartz.threadPool.class > otherwise by default we put a thread factory using daemon threads)? > > *Romain Manni-Bucau* > *Twitter: @rmannibucau* > *Blog: http://rmannibucau.wordpress.com* > > > > > 2012/8/18 Enrico Olivelli <[email protected]> > >> Hi all, >> I'm continuing with tests on Quartz and TomEE and Jobstore on DB. >> I found this interesting situation: >> - start Tomee with Quartz configured with a JobStore on a shared DB in >> order to deploy "clustered" EJB timeouts >> - shutdown the database >> - try to stop TomEE >> >> The JVM will never shutdown, hung on (I think) Quartz non deamon threads >> >> Personally I think this is more a Tomcat problem, I never liked Tomcat >> shutdown process >> I agree that for the container (Tomcat) it is a good thing to let all >> thread stop gracefully but is a real world scenario you would like to be >> able to stop your Tomcat without the need of a "kill -KILL" >> >> this scenario cannot be easily reproduced on a JUnit test case >> >> - Enrico >> >> >> >
