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