[
https://issues.apache.org/jira/browse/FELIX-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated FELIX-5215:
----------------------------------
Attachment: deadlock-02.txt
deadlock-01.txt
Threaddumps showing deadlocks for reference.
Other similar situations were reported in FELIX-3839, FELIX-3761 and FELIX-3644.
In FELIX-3067 [~fmeschbe] proposed using a timeout in the global lock to remedy
the same situation.
> 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-4.6.1, framework-5.4.0
> Reporter: Julian Sedding
> Attachments: deadlock-01.txt, deadlock-02.txt
>
>
> 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)
