retry tomorrow, nightly build should have redeployed the snasphot and it should contain the fix
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-04-20 15:00 GMT+02:00 tschuler <[email protected]>: > Hi Romain! > > The suggested workaround preloading the locking classes in a > ServletContextListener might work, but: > The thread deadlock happens only from time to time (about every 5th day). > Therefore identifying the locking classes is not possible as we observe a > different one every time. Additionally a customer might enhance the > application adding additional classes that may result in deadlock situation > while classloading. > > And yes - classloader has two locks (one at java classloader and one at the > openejb classloader). > > Please let us know if a potential fix is available - so that we can use a > TomEE snapshot to check it. > > Best regards, > Thomas > > > > -- > View this message in context: > http://tomee-openejb.979440.n4.nabble.com/thread-deadlock-at-URLClassLoaderFirst-tp4674197p4674508.html > Sent from the TomEE Users mailing list archive at Nabble.com. >
