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.

Reply via email to