[
https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696102#action_12696102
]
Stuart McCulloch commented on FELIX-1027:
-----------------------------------------
It certainly seems related, because even if you used an unrelated lock object
(ie. local to the class) you would still get the second deadlock because of the
synchronized loadClassInternal in the JDK ClassLoader code.
There is an experimental workaround you could try if you use the Sun JDK (or
you could perhaps try the IBM JDK):
-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass
from
http://underlap.blogspot.com/2006/11/experimental-fix-for-sunbug-4670071.html
Alternatively you could look into introducing a higher-level synchronization
into your application code to avoid the situation to begin with (I know, this
sucks)
> deadlock with felix 1.6.0 ?
> ---------------------------
>
> Key: FELIX-1027
> URL: https://issues.apache.org/jira/browse/FELIX-1027
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Environment: jdk1.5, linux
> Reporter: Pierre De Rop
> Priority: Critical
> Attachments: deadlock.txt,
> deadlock_after_patch_FELIX_1027_20090406.log, FELIX_1027_20090406.txt
>
>
> I just came across a deadlock with the felix 1.6.0 candidate version for the
> next fwk version.
> I have attached to this post the corresponding "kill -QUIT" output.
> Richard, is it really an framework deadlock ? This is strange because I am
> testing the trunk since one month and never noticed the problem ...
> /pierre
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
