[
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.
