You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2008/09/29 16:53:45 UTC
[jira] Created: (FELIX-748) Deadlock with class loading and
URLHandlers
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.
[jira] Closed: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Pauls closed FELIX-748.
----------------------------
Resolution: Fixed
I commited the patch to trunk (rev 706790).
> 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
> Assignee: Karl Pauls
> Fix For: felix-1.4.0
>
> Attachments: FELIX-748-deadlock.txt, URLHandlers.patch
>
>
> 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.
Re: [jira] Updated: (FELIX-748) Deadlock with class loading and URLHandlers
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Simon,
Simon Kaegi schrieb:
> Felix,
>
> do you know if a similar bug should be logged against Equinox. It's
> quite likely that we're using a similar approach.
Not sure, because the synchronization is an implementation detail of the
Felix implementation and I am not sure, whether the Eclipse
implementation suffers from this problem ..
With respect to the Class.forName() problem, I am also not sure, whether
Eclipse uses this.
Regards
Felix
> Thanks.
> -Simon
>
> ----- Original Message ----- From: "Felix Meschberger (JIRA)"
> <ji...@apache.org>
> To: <de...@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.
>>
>
>
Re: [jira] Updated: (FELIX-748) Deadlock with class loading and URLHandlers
Posted by Simon Kaegi <si...@gmail.com>.
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)" <ji...@apache.org>
To: <de...@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.
>
[jira] Updated: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635824#action_12635824 ]
Felix Meschberger commented on FELIX-748:
-----------------------------------------
Thanks for the quick fix/patch. I will try to reproduce our issue without and with your patch as soon as poosible -- since I am only half-working this week, this may take until next week.
> 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, URLHandlers.patch
>
>
> 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.
[jira] Commented: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641385#action_12641385 ]
Felix Meschberger commented on FELIX-748:
-----------------------------------------
Just tested your patch with framework trunk and it seems to work. Thanks.
> 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
> Assignee: Karl Pauls
> Attachments: FELIX-748-deadlock.txt, URLHandlers.patch
>
>
> 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.
[jira] Commented: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635454#action_12635454 ]
Felix Meschberger commented on FELIX-748:
-----------------------------------------
Thanks for the feedback. Will have a look into this -- we are still on framework 1.0.4 so a first step would be to 1.2.1 ;-)
> 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.
[jira] Updated: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Pauls updated FELIX-748:
-----------------------------
Fix Version/s: felix-1.4.0
> 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
> Assignee: Karl Pauls
> Fix For: felix-1.4.0
>
> Attachments: FELIX-748-deadlock.txt, URLHandlers.patch
>
>
> 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.
[jira] Commented: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639767#action_12639767 ]
Karl Pauls commented on FELIX-748:
----------------------------------
Any news on this one?
> 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
> Assignee: Karl Pauls
> Attachments: FELIX-748-deadlock.txt, URLHandlers.patch
>
>
> 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.
[jira] Assigned: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Pauls reassigned FELIX-748:
--------------------------------
Assignee: Karl Pauls
> 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
> Assignee: Karl Pauls
> Attachments: FELIX-748-deadlock.txt, URLHandlers.patch
>
>
> 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.
[jira] Updated: (FELIX-748) Deadlock with class loading and
URLHandlers
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Pauls updated FELIX-748:
-----------------------------
Attachment: URLHandlers.patch
This patch should work with felix-1.0.4 and felix-1.2.1
Can you please test it and see whether it makes your issues go away (and doesn't create new :-)
> 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, URLHandlers.patch
>
>
> 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.