[
https://issues.apache.org/jira/browse/FELIX-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall updated FELIX-2597:
-----------------------------------
Fix Version/s: framework-3.0.3
(was: framework-3.2.0)
> Deadlock during delivery of resolved event
> ------------------------------------------
>
> Key: FELIX-2597
> URL: https://issues.apache.org/jira/browse/FELIX-2597
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Affects Versions: framework-3.0.2
> Reporter: Richard S. Hall
> Assignee: Richard S. Hall
> Priority: Minor
> Fix For: framework-3.0.3
>
>
> When the framework resolves a bundle, it fires the RESOLVED event to
> synchronous bundle listeners while holding the global lock. This caused a
> deadlock in a specific scenario where two threads T1 and T2 were racing to
> resolve bundles B1 and B2, respectively. T1 was resolving a dynamic import
> for B1 which started from a loadClassInternal() call from the JVM which locks
> B1's class loader. T1 lost the race for the global lock and had to wait for
> T2 to do its resolve of B2. T2 resolved B2 and ended up firing a RESOLVED
> event to B1. In B1's callback method, a loadClassInternal() was triggered by
> T2 when it accessed some static, which caused it to deadlock when the JRE
> tried to lock the B1's class loader on T2, which was already held by T1.
> This issue is actually related to the JVM being too aggressively in its
> locking of class loaders:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4670071
> Regardless, we might be able to loosen this up a little bit by not holding
> the global lock at all. This might slightly violate the definition of
> synchronous bundle listener, since the state could change, but at least it
> will still be delivered synchronously on the instigating thread.
> More information here:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=13329
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
