You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Pierre De Rop (JIRA)" <ji...@apache.org> on 2009/04/06 13:44:13 UTC
[jira] Created: (FELIX-1027) deadlock with felix 1.6.0 ?
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
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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696954#action_12696954 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
Yes Richard, I remember, and in the sample code, I think I don't have such race condition (though, I am now doubting ...) because:
1) the Updater always stops the bundle B, before upadting/refreshing it.
2) In B.stop(), I ensure all started threads to be properly joined, before returning from B.stop() method.
3) Morover, when I refresh, I always wait for the PACKAGES_REFRESHED event, before restarting B ...
Did I miss something ?
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696226#action_12696226 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
Stuart,
I forgot to ask the following:
1) is it really safe to use UnsyncloadClass with Felix ? I saw that this option is unstable and "calls loadClass unsynchronized. Custom classloader must call VM synchronized for findClass & defineClass" ...
2) moreover, does the option "UnlockDiagnosticVMOptions" affect jvm performances ?
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697773#action_12697773 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
Richard,
I reproduce the problem in a simpler way, without using the "Updater" bundle at all. (yon can discard it).
Now, in my felix config, I just start bundle A, and B:
----------------------------------
felix.auto.start.1= \
file:bundle/org.apache.felix.shell-1.1.0-SNAPSHOT.jar \
file:bundle/org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar \
file:bundle/org.apache.felix.bundlerepository-1.3.0-SNAPSHOT.jar \
file:bundle/A.jar \
file:bundle/B.jar \
# don't activate felix debug ...
felix.log.level=1
---------------------------------------------------------------------------
and I start felix like this (I use jdk 1.5.0_18):
rm -rf felix-cache/;
java -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass -jar bin/felix.jar
-> B starting ...
java.lang.ClassNotFoundException: a.A
at org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:565)
at org.apache.felix.framework.searchpolicy.ModuleImpl.access$100(ModuleImpl.java:59)
at org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1434)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at b.Legacy.run(Legacy.java:6)
at java.lang.Thread.run(Thread.java:595)
If you don't get the CNF, then manually stop/update/refresh/start bundle B, like this, and you will probably get the CNF:
-> B starting ...
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.7.0.SNAPSHOT)
[ 1] [Active ] [ 1] Apache Felix Shell Service (1.1.0.SNAPSHOT)
[ 2] [Active ] [ 1] Apache Felix Shell TUI (1.1.0.SNAPSHOT)
[ 3] [Active ] [ 1] Apache Felix Bundle Repository (1.3.0.SNAPSHOT)
[ 4] [Active ] [ 1] A (1.0.0)
[ 5] [Active ] [ 1] B (1.0.0)
-> stop 5
-> update 5
-> refresh 5
-> start 5
B starting ...
java.lang.ClassNotFoundException: a.A
at org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:565)
at org.apache.felix.framework.searchpolicy.ModuleImpl.access$100(ModuleImpl.java:59)
at org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1434)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at b.Legacy.run(Legacy.java:6)
at java.lang.Thread.run(Thread.java:619)
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698066#action_12698066 ]
Richard S. Hall commented on FELIX-1027:
----------------------------------------
I have attached a patch that performs double checking of the wire before attempting to dynamically import again. I believe this resolves the issue for this example. Not sure if the precise patch is good in general. It does result in some duplication with Resolver.isDynamicImportAllowed().
> 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
> Assignee: Karl Pauls
> Priority: Critical
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX-1027-double-check.txt, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Updated: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1027:
-----------------------------------
Attachment: FELIX-1027-double-check.txt
> 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
> Assignee: Karl Pauls
> Priority: Critical
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX-1027-double-check.txt, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696231#action_12696231 ]
Karl Pauls commented on FELIX-1027:
-----------------------------------
In regard to 1, yes it should be save as we do our own (more finegrained locking). Not sure about 2.
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697735#action_12697735 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
Richard,
I don't think that the Auto-Refresh issue is unrelated to this one (that's why I sent the auto-refresh issue on users-list, separately).
To work around the Auto-Refresh problem, I have added a sleep(10) in the Updater.Refresher inner class.
I just tested with a higher delay (5000), and I still have the ClassNotFound with the -XX options
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696956#action_12696956 ]
Richard S. Hall commented on FELIX-1027:
----------------------------------------
Pierre, that sounds reasonable. I guess we will have to look into your example.
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Updated: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1027:
-----------------------------------
Attachment: (was: FELIX-1027.txt)
> 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
> Assignee: Karl Pauls
> Priority: Critical
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696056#action_12696056 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
The bundles involved in the deadlock are not mine, but using the stacktraces, I think I could try to
reproduce this issue. I'll let you know asap;
> 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
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696053#action_12696053 ]
Stuart McCulloch commented on FELIX-1027:
-----------------------------------------
This certainly looks like a deadlock - and afaik there was some recent work done in this area which may have introduced this.
Do you happen to have a reproducible testcase? or even a smallish private testcase you could send to Richard and/or me?
> 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
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696383#action_12696383 ]
Stuart McCulloch commented on FELIX-1027:
-----------------------------------------
@Pierre as Karl said using this switch should be safe because the custom Felix classloader has extra fine-grained locks to protect against collisions - also "UnlockDiagnosticVMOptions" just unlocks additional diagnostic options, to the best of my knowledge it doesn't affect JVM performance unless you specify further switches (think of it as a safety-catch)
@Don unfortunately the deadlock in loadClassInternal cannot be fixed in Felix because the JVM can call loadClassInternal directly in certain situations which means that even introducing a global lock in Felix may not help (a global lock would also really hurt performance for everyone), if you look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071 this is a long-standing bug in the Sun JVM that can occasionally occur during parallel classloading with any classloader that doesn't follow the parent-delegation model (the original bug was raised back in 2002 by someone using a custom JBoss classloader)
Other JVMs (like IBM) don't have synchronized on loadClassInternal and therefore don't suffer from this bug - also note from the latest evaluation report on the sunbug, that Sun have finally decided on a different fix which requires custom classloaders requiring parallel classloading to use a special (currently non-standard) API - but this is only available in very recent JDK builds and afaik would require us to use some reflection magic...
In practice this deadlock only affects applications with parallel classloading involving the same set of classes - because most OSGi applications load their classes during resolution or in the bundle activator, this doesn't affect them - only a sub-set of applications that use Class.forName, etc. for the same set of classes in different threads at exactly the same time may be affected.
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698815#action_12698815 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
All right, I have performed a non-regression test, and it looks like everything is ok with your patch and with the -XX options ...
Thanks !
Do you plan to commit this fix, or do you need to investigate further ?
> 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
> Assignee: Karl Pauls
> Priority: Critical
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX-1027-double-check.txt, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697728#action_12697728 ]
Richard S. Hall commented on FELIX-1027:
----------------------------------------
Pierre, are the exceptions you are seeing related to the fact that update auto-refreshes? Your comment in your code mentions that the refresh isn't done when you receive the event. I guess it is clear now that your Updater was seeing the event of the auto-refresh, not its own refresh. Does this resolve this issue?
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696936#action_12696936 ]
Richard S. Hall commented on FELIX-1027:
----------------------------------------
Pierre, it seems that constantly updating/refreshing your bundles is always going to lead to such situations since you have a race condition between servicing the class load request and the JAR file being deleted from the file system due to a refresh.
Remember that we do not try to perform any locking on a class load to hold a bundle JAR file in place because a) it would be too costly, b) the potential for deadlock would be great, and c) what's the point since if the bundle you depend on is being refreshed, then you are likely being refreshed too.
You concern here seems to be based on the fact that you do not see these errors with the JVM option enabled, but perhaps that makes some sense since it leads to more concurrency, which then exposes this race condition. Just a thought.
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Assigned: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karl Pauls reassigned FELIX-1027:
---------------------------------
Assignee: Karl Pauls
> 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
> Assignee: Karl Pauls
> Priority: Critical
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696073#action_12696073 ]
Stuart McCulloch commented on FELIX-1027:
-----------------------------------------
See also: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071
Some deadlocks can happen with OSGi style classloading because of the spurious synchronization on loadClassInternal, so as Karl just pointed out to me you might still get an exception even with this patch - but the timing window should be much narrower...
( BTW the solution chosen by Sun to support this sort of 'parallel class loading' is to use a special API, but I can't seem to find the exact details at the moment... )
> 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, 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.
[jira] Updated: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre De Rop updated FELIX-1027:
---------------------------------
Attachment: test-deadlock.tgz
attached the sample code which have ClassNotFoundException, when using the "-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass" options.
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Updated: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1027:
-----------------------------------
Fix Version/s: (was: felix-1.8.0)
felix-1.6.1
> 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
> Assignee: Richard S. Hall
> Priority: Critical
> Fix For: felix-1.6.1
>
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX-1027-double-check.txt, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697738#action_12697738 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
(oops, my previous message was not clear, I repost it):
the Auto-Refresh is (I think) UNRELATED to the ClassNotFound (and you can replace sleep(10) by sleep(5000) in the Updated.java file -> you will have the same ClassNotFound with -XX options)
/pierre
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Sahoo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697600#action_12697600 ]
Sahoo commented on FELIX-1027:
------------------------------
Stuart,
The classloader API changes are discussed at:
http://openjdk.java.net/groups/core-libs/ClassLoaderProposal.html
Thanks,
Sahoo
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Updated: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre De Rop updated FELIX-1027:
---------------------------------
Attachment: deadlock.txt
> 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
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Karl Pauls (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696104#action_12696104 ]
Karl Pauls commented on FELIX-1027:
-----------------------------------
Sometimes it helps when you check whether you can rearrange your import/export packages. Basically, for this to happen the one need to import from the other. If that is they way you want to structure your bundles then you have to try what Stuart suggests but otherwise, you could see whether you can repackage in a way that avoids this issue.
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696903#action_12696903 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
I must say I am somewhat worried about this deadlock issue, and may we we should reopen this ticket ?
Stuard, Karl, I let you re-open it if you think it makes sense.
Let me explain:
---------------------
First of all, I just would like to notice that the problem I am facing here is a story of legacy code which is
using Class.forName, and I just can't modify this legacy code in order to replace the Class.forName by anything
else, like the OSGi registry. Indeed, I could rework the legacy code in order to register class implementations
inside the OSGi registry, and inject them in client bundles (using iPOJO, SCR, etc ...).
But the point is: I just can't modify the code, it's not mine.
Morover, I would like to notice that many third party open source libraries (like log4j for instance) rely on
class.forName, and we can't ignore this fact ... Think of Log4j, which loads Appenders using Class.forName ...
So, now, here is my problem: Yesterday, I successfully started my app server with the options
"UnlockDiagnosticVMOptions/UnsyncloadClass", without any deadlocks. So far so good.
Now, I have made a sample code in order to be able to get the problem in a reproducible way .
My intent here was to make a Junit auto-test and verify that the UnlockDiagnosticVMOptions/UnsyncloadClass
options really resolves the issue.
But Unfortunately, the sample code does not reproduce the deadlock.
However, and this is the point of this issue, when I run my sample code with the
UnlockDiagnosticVMOptions/UnsyncloadClass, then I get some abnormal ClassNotFoundException
(and I don't have them without the mentioned options !)
I have attached to this post the sample code. May be I did a mistake ? can you look into it, please.
sample code description:
-----------------------------------
- The bundle "A" export the package "a" with a class a.A
- The Bundle "B", when started, fires some threads which perform Class.forName("a.A").newInstance()
(B does an ugly "DynamicImport-Package: *)
- The Bundle "Updater" constantly updates the bundles A,B and refreshes them, using PackageAdmin.refresh(null).
Hence, I ensure that wiring is re-done after each updates.
- Without, the UnlockDiagnosticVMOptions/UnsyncloadClass, I get the following traces (I have activated
felix.log.level=4), and I don't have any deadlocks (unfortunately ..., well ...):
rm -rf felix-cache/; java -server -jar bin/felix.jar
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 10.0 -> org.osgi.service.packageadmin -> 0
DEBUG: WIRE: 10.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
etc ...
- With the -XX options, I then get the following abnormal exceptions:
rm -rf felix-cache/; java -server -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass -jar bin/felix.jar
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 10.0 -> org.osgi.service.packageadmin -> 0
DEBUG: WIRE: 10.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
DEBUG: WIRE: 9.0 -> org.osgi.framework -> 0
B starting ...
DEBUG: DYNAMIC WIRE: 9.0 -> a -> 8.0
java.lang.ClassNotFoundException: *** Package 'a' is imported by bundle 9 from bundle 8, but the exported package from bundle 8 does not contain the requested class 'a.A'. Please verify that the class name is correct in the importing bundle 9 and/or that the exported package is correctly bundled in 8. ***
at org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1448)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at b.Legacy.run(Legacy.java:6)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException: a.A
at org.apache.felix.framework.searchpolicy.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:565)
at org.apache.felix.framework.searchpolicy.ModuleImpl.access$100(ModuleImpl.java:59)
at org.apache.felix.framework.searchpolicy.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1434)
... 5 more
-> Could anyone please check my sample code. I am just worried about unexpected side effects from the -XX options ...
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696085#action_12696085 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
Stuarts,
Thank you for your patch and quick response.
Now, I have applied your patch but got another dead lock, with a different stacktrace than without your fix (I attached it).
do you think I am getting the deadlock mentioned by Karl ?
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696151#action_12696151 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
As far as I understand, the issue arises because I use class.forName from my Activators. The first Activator.start() method invokes
class.forName from the "FelixStartLevel" thread, and the other class.forName is invoked concurrently, from another thread which is
started by the second activator.
I am actually struggling with some legacy code which is using Class.forName() ...
In any case, I think that using Class.ForName is definitely a poor practice in OSGi, and I will try to work around this problem
by just replacing the Class.forName() with the OSGi Registry ...
So, if you think there is nothing to fix at all in the framework, may be I should close this fault report ?
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696060#action_12696060 ]
Stuart McCulloch commented on FELIX-1027:
-----------------------------------------
I wonder if using another object for the Felix specific locking would solve this (ie. instead of the classloader itself) - at the moment this internal lock is conflicting with the standard classloader lock.
> 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
>
>
> 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.
[jira] Resolved: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall resolved FELIX-1027.
------------------------------------
Resolution: Fixed
Fix Version/s: felix-1.8.0
Assignee: Richard S. Hall (was: Karl Pauls)
I have committed my simple double-check patch. Please close this issue if you are satisfied. Thanks.
> 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
> Assignee: Richard S. Hall
> Priority: Critical
> Fix For: felix-1.8.0
>
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX-1027-double-check.txt, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699027#action_12699027 ]
Richard S. Hall commented on FELIX-1027:
----------------------------------------
We will commit it or something like it. I still want to look into improving the patch so it doesn't duplicate code, but otherwise it is probably ok.
> 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
> Assignee: Karl Pauls
> Priority: Critical
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX-1027-double-check.txt, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Updated: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stuart McCulloch updated FELIX-1027:
------------------------------------
Attachment: FELIX_1027_20090406.txt
Pierre, could you apply this patch to the current Felix trunk (or the 1.6.0 framework source) to see if it solves your deadlock?
> 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, 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.
[jira] Updated: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard S. Hall updated FELIX-1027:
-----------------------------------
Attachment: FELIX-1027.txt
> 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
> Assignee: Karl Pauls
> Priority: Critical
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Don Brown (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696333#action_12696333 ]
Don Brown commented on FELIX-1027:
----------------------------------
That's great that you can work around it with a set of Sun-specific command line arguments, but that does nothing to help with folks like me that have no control over what JVM the application is deployed on. I think this issue should be reopened until it is fixed properly in Felix.
> 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.
[jira] Reopened: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stuart McCulloch reopened FELIX-1027:
-------------------------------------
Re-opening so we (ie. either me/Karl/Richard) can do further investigation
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698060#action_12698060 ]
Richard S. Hall commented on FELIX-1027:
----------------------------------------
Ok, I think I know what is going on here and it is a bug in Felix which is exposed by the additional level of concurrency enabled by the new JVM flag.
Basically, the situation is something like this:
1. Since the bundle is dynamically importing "a", there is a race condition among its threads to be the first to dynamically import it.
2. Assume all threads approximately finish searching their statically imported wires at the same time, none will find "a.A" because it hasn't been dynamically imported yet.
3. Further assume all threads end up trying to dynamically import "a" at around the same time; only one will actually be able to do so, because this operation is guarded by a global lock.
4. Whichever thread won the race to dynamically import the package will succeed in doing so and will load the class correctly.
5. All remaining threads will also [one at a time] try to dynamically import the package, but each will fail since the bundle now already imports the package as a result of the first thread. You are not allowed to dynamically import a package to which you are already wired.
6. Since the remaining bundles are all past the point where they can search their existing imports, each thread will throw a CNFE, since it looks like to them that the dynamic import failed.
I am pretty sure this is what is going on. The solution? We probably need to double-check to make sure the package hasn't already been dynamically imported when we attempt to dynamic import to detect the race condition.
I quickly hacked up a solution in my workspace and it looks like I am on the correct track, but I don't have a complete patch ready yet.
> 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
> Assignee: Karl Pauls
> Priority: Critical
> Attachments: deadlock.txt, deadlock_after_patch_FELIX_1027_20090406.log, FELIX_1027_20090406.txt, test-deadlock.tgz
>
>
> 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.
[jira] Closed: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre De Rop closed FELIX-1027.
--------------------------------
Resolution: Fixed
issue closed because the JVM options "-XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass" seems to resolve the problem.
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696214#action_12696214 ]
Pierre De Rop commented on FELIX-1027:
--------------------------------------
Stuart,
I just tested the " -XX:+UnlockDiagnosticVMOptions -XX:+UnsyncloadClass" options and it sounds to work fine.
A big thanks !
(I will close this issue)
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697774#action_12697774 ]
Richard S. Hall commented on FELIX-1027:
----------------------------------------
Ok, thanks for the update. We are looking into it.
> 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, test-deadlock.tgz
>
>
> 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.
[jira] Updated: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Pierre De Rop (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pierre De Rop updated FELIX-1027:
---------------------------------
Attachment: deadlock_after_patch_FELIX_1027_20090406.log
> 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.
[jira] Commented: (FELIX-1027) deadlock with felix 1.6.0 ?
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ 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.