Felix,
do you know if a similar bug should be logged against Equinox. It's quite
likely that we're using a similar approach.
Thanks.
-Simon
----- Original Message -----
From: "Felix Meschberger (JIRA)" <[EMAIL PROTECTED]>
To: <dev@felix.apache.org>
Sent: Monday, September 29, 2008 10:53 AM
Subject: [jira] Updated: (FELIX-748) Deadlock with class loading and
URLHandlers
[
https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated FELIX-748:
------------------------------------
Attachment: FELIX-748-deadlock.txt
Here is the full stacktrace of the three deadlocking threads.
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.
