PS: see also FELIX-5215
On Mon, Mar 14, 2016 at 6:00 PM, Julian Sedding wrote:
> Hi all
>
> 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):
>
> "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. [...]"
>
> WDYT? Any ideas on how this could be approached?
>
> Thanks & regards
> Julian