Le 20 avr. 2015 13:51, "tschuler" <[email protected]> a écrit : > > Hi all! > > We got about ten thread dumps right now with threads in deadlock situation. > The pattern is always the same (see attachment DeadlockThreadsPattern.txt > DeadlockThreadsPattern.txt > < http://tomee-openejb.979440.n4.nabble.com/file/n4674503/DeadlockThreadsPattern.txt > > ). > > All thread dumps have in common: > - thread blocked in checkCerts method (java.lang.ClassLoader) results from > an HTTP request. > - thread blocked in loadClass method > (org.apache.openejb.util.classloader.URLClassLoaderFirst) is triggered > internally, e.g. a message driven bean or a scheduled bean is executed. > > Getting a heap dump shows that exactly one instance of > org.apache.openejb.util.classloader.URLClassLoaderFirst exists (in compare > to e.g. 18 instances of the java.net.URLClassLoader). > It seems that the internal trigger (e.g. for a MDB) somewhere locks the only > available instance of URLClassLoaderFirst before achieving the ReentrantLock > in loadClass method of URLClassLoaderFirst. > The only way we can see that this could happen is the private method > loadClassInternal(String) in java.lang.ClassLoader. >
Not sure I got what you mean. Issue is the classloader has 2 locks. I ll fix it tonight. That said previous workarounds should work. > Maybe someone with more insight in TomEE/Tomcat internals or classloading > can give a hint how to avoid the deadlock situation? > Is there a way to configure TomEE for replacing the URLClassLoaderFirst with > an own implementation to see if removing the ReentrantLock would solve the > thread deadlocks? > We are open for ideas what can be done to identify the root cause for the > deadlock situation. > > Best regards, > Thomas > > > > -- > View this message in context: http://tomee-openejb.979440.n4.nabble.com/thread-deadlock-at-URLClassLoaderFirst-tp4674197p4674503.html > Sent from the TomEE Users mailing list archive at Nabble.com.
