Do you mean because the thread that is deadlocked is the QuartzSchedulerThread?
The classloader and the concurrent thread are both waiting on Quartz. Quartz thread is defined below: (Other than that I do not know what you mean when you say it is not consistent.) Should I provide the full dump in a ticket? "Event Manager Thread_QuartzSchedulerThread": at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:769) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2283) - locked <0x00001000bbc1dd20> (a java.lang.Object) at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:811) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1260) - locked <0x00001000bbc1dd20> (a java.lang.Object) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1119) at org.quartz.simpl.LoadingLoaderClassLoadHelper.loadClass(LoadingLoaderClassLoadHelper.java:59) at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.java:99) at org.quartz.simpl.CascadingClassLoadHelper.loadClass(CascadingClassLoadHelper.java:138) at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectJobDetail(StdJDBCDelegate.java:852) at org.quartz.impl.jdbcjobstore.JobStoreSupport.retrieveJob(JobStoreSupport.java:1385) at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTrigger(JobStoreSupport.java:2818) 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:3799) at org.quartz.impl.jdbcjobstore.JobStoreSupport.acquireNextTriggers(JobStoreSupport.java:2756) at org.quartz.core.QuartzSchedulerThread.run(QuartzSchedulerThread.java:272) On Tue, Nov 20, 2018 at 3:20 PM Mark Thomas <ma...@apache.org> wrote: > The thread dump you posted doesn't seem to be consistent with the > summary you provide below. Specifically for the "Event Manager > Thread_QuartzSchedulerThread". Might there be multiple threads with that > name and we are looking at the wrong one? > > Mark > > > On 20/11/2018 19:06, Andrew Carr wrote: > > My apologies, that is the offending thread, see below: (Should I open a > > ticket to attach full dumps?) > > > > Found one Java-level deadlock: > > ============================= > > "Thread-96": > > waiting to lock monitor 0x3a0d6938 (object 0x80048462700, a > > java.util.concurrent.ConcurrentHashMap), > > which is held by "Thread-29" > > "Thread-29": > > waiting to lock monitor 0x3a0d58b0 (object 0x1000bbc1dd20, a > > java.lang.Object), > > which is held by "Event Manager Thread_QuartzSchedulerThread" > > "Event Manager Thread_QuartzSchedulerThread": > > waiting to lock monitor 0x3803a2c0 (object 0x800674b7830, a > > org.apache.catalina.loader.ParallelWebappClassLoader), > > which is held by "Thread-29" > > > > > > On Tue, Nov 20, 2018 at 12:50 PM Mark Thomas <ma...@apache.org> wrote: > > > >> On 20/11/2018 15:21, Andrew Carr wrote: > >>> Hello, > >>> > >>> We have been seeing some intermittent issues with the parallel > >>> classloader. I do not want to jump to any conclusions and say this is > a > >>> bug w/ the classloader, but we are getting deadlocked threads, pretty > >>> randomly, when launching the server. I was wondering if anyone had > >>> experienced this issue or if you could review the attached thread dump > >> and > >>> give me some feedback. > >>> > >>> There is no associated log file for the time the deadlock was > occurring, > >> I > >>> am working on getting that. In unrelated log files I saw some > >> concurrency > >>> exceptions, non-thread safe access to lists basically. I believe that > >>> issue has been corrected in the source code, and I am not sure the > >>> concurrency exception has anything to do with the deadlock occurring > >> during > >>> classloading. > >>> > >>> Personally I am of the belief that unsafe maps / lists could possibly > >> cause > >>> the classloader to deadlock. > >>> > >>> I can put the full dumps in a ticket, I just hate to open another > >>> classloader ticket. > >> > >> I don't see a deadlock in the provided stack trace. > >> > >> Mark > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- With Regards, Andrew Carr e. andrewlanec...@gmail.com w. andrew.c...@openlogic.com c. 4239489206 a. P.O. Box 1231, Greeneville, TN, 37744
