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