Julian Sedding created FELIX-5215:
-------------------------------------
Summary: Deadlocks involving global lock
Key: FELIX-5215
URL: https://issues.apache.org/jira/browse/FELIX-5215
Project: Felix
Issue Type: Improvement
Components: Framework
Affects Versions: framework-5.4.0, framework-4.6.1
Reporter: Julian Sedding
I have recently analyzed two thread dumps on a framework 4.6.1 with deadlocks
involving the {{FelixFrameworkWiring}} thread calling {{Felix.refreshPackages}}
and another thread.
In both cases the {{FelixFrameworkWiring}} thread holds Felix' global lock in
{{Felix.refreshPackages}}, the other thread holds a lock in {{HttpServiceImpl}}
and {{ServiceRegistry}}, respectively. (Note, both {{HttpServiceImpl}} and
{{ServiceRegistry}} had their synchronization removed in trunk, possibly due to
similar deadlocks).
While fixing the other players in the deadlock certainly helps, I was wondering
if it would be possible to change the code inside the framework in a way that
such deadlocks are no longer possible?
I believe section 4.7.3 "Synchronization Pitfalls" in the OSGi spec talks about
this situation (quoted from v5.0.0):
{quote}
Generally, a bundle that calls a listener should not hold any Java monitors.
This means that neither the Framework nor the originator of a synchronous event
should be in a monitor when a callback is initiated.
[...]
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
