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.
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.
