PS: see also FELIX-5215
On Mon, Mar 14, 2016 at 6:00 PM, Julian Sedding <[email protected]> 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
