Deadlock with class loading and URLHandlers -------------------------------------------
Key: FELIX-748 URL: https://issues.apache.org/jira/browse/FELIX-748 Project: Felix Issue Type: Bug Components: Framework Affects Versions: felix-1.0.4 Reporter: Felix Meschberger Attachments: FELIX-748-deadlock.txt We have a tricky dead lock issue involving Java ClassLoaders and the Felix framework URLHandlers class. We have two web apps: An Apache Sling web app using Felix as its framework and a second Web App providing a JCR repository. While starting up, someone is accessing the JCR repository web app which causes a JSP compilation. This involves class loading and calls into the Felix URLHandlers to create some URL. The deadlock description is: Found one Java-level deadlock: ============================= "SimpleQuartzScheduler_QuartzSchedulerThread": waiting to lock monitor 0x0aaa6634 (object 0x03256ac0, a java.net.URLClassLoader), which is held by "SCR Component Actor" "SCR Component Actor": waiting to lock monitor 0x0aaa65cc (object 0x02ebba58, a java.net.URLClassLoader), which is held by "127.0.0.1 [1222693412656] GET /crx/browser/index.jsp HTTP/1.1" "127.0.0.1 [1222693412656] GET /crx/browser/index.jsp HTTP/1.1": waiting to lock monitor 0x0aaa6634 (object 0x03256ac0, a java.net.URLClassLoader), which is held by "SCR Component Actor" Looking at the code, it seems, that the URLHandlers.createURLStreamHandler class is using a synchronized blog which looks too big. In addition it uses the SecureAction.forName method, which in turn uses Class.forName, which has its issues, too. So maybe the URLHandlers.createURLStreamHandler method should employ a different synchronization mechanism so as to avoid deadlocks through classloaders. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.