[
https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635441#action_12635441
]
Karl Pauls commented on FELIX-748:
----------------------------------
I think it should be enough to make both, the addToStreamCache and the
addToContentCache methods synchronized. Then the sychronized block in both, the
createUrlStreamHandler and createContentHandler methods can be narrowed down to
protect the first line.
Maybe you could try whether that works. I can create a patch but not before
tomorrow evening...
> 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.
