felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Sedding (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-5215) Deadlocks involving global lock
Date Mon, 14 Mar 2016 16:58:33 GMT

     [ 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

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

View raw message