[jira] Closed: (FELIX-836) Deadlocks caused by Declarative Services

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FELIX-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler closed FELIX-836.
----------------------------------


> Deadlocks caused by Declarative Services
> ----------------------------------------
>
>                 Key: FELIX-836
>                 URL: https://issues.apache.org/jira/browse/FELIX-836
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.0.6
>            Reporter: Felix Meschberger
>            Assignee: Felix Meschberger
>             Fix For: scr-1.0.8
>
>         Attachments: FELIX-836.patch
>
>
> We experience deadlocks with Declarative Services every now and then related to the interaction between the framework and SCR. The situation most often happens when multiple bundles are uptated and packages are refreshed.
> One thread involved is the "SCR Component Actor" thread, which is the thread of SCR running asynchronous operations on registered components. The other thread is the framework PackageAdmin thread which stops and starts bundles during refresh:
> ---- thread dump excerpt ----
> "SCR Component Actor" daemon prio=5 tid=0x0107f9c0 nid=0xab2400 in Object.wait() [0xb18a2000..0xb18a2d90]
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x075e2d58> (a [Ljava.lang.Object;)
> 	at java.lang.Object.wait(Object.java:474)
> 	at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4167)
> 	- locked <0x075e2d58> (a [Ljava.lang.Object;)
> 	at org.apache.felix.framework.Felix.registerService(Felix.java:2665)
> 	at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:254)
> 	at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:232)
> 	at org.apache.sling.scripting.core.impl.ScriptEngineConsolePlugin.activate(ScriptEngineConsolePlugin.java:171)
> 	at org.apache.sling.scripting.core.impl.ScriptEngineConsolePlugin.initPlugin(ScriptEngineConsolePlugin.java:52)
> 	at org.apache.sling.scripting.core.impl.SlingScriptAdapterFactory.activate(SlingScriptAdapterFactory.java:223)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.apache.felix.scr.impl.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:226)
> 	at org.apache.felix.scr.impl.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:133)
> 	at org.apache.felix.scr.impl.AbstractComponentManager.activateInternal(AbstractComponentManager.java:476)
> 	- locked <0x0976ca30> (a org.apache.felix.scr.impl.ImmediateComponentManager)
> 	at org.apache.felix.scr.impl.AbstractComponentManager.enableInternal(AbstractComponentManager.java:398)
> 	at org.apache.felix.scr.impl.AbstractComponentManager.access$000(AbstractComponentManager.java:36)
> 	at org.apache.felix.scr.impl.AbstractComponentManager$1.run(AbstractComponentManager.java:99)
> 	at org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:85)
> "FelixPackageAdmin" daemon prio=5 tid=0x0106f330 nid=0xaad000 waiting for monitor entry [0xb171f000..0xb171fd90]
> 	at org.apache.felix.scr.impl.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:540)
> 	- waiting to lock <0x0976ca30> (a org.apache.felix.scr.impl.ImmediateComponentManager)
> 	at org.apache.felix.scr.impl.AbstractComponentManager.disableInternal(AbstractComponentManager.java:579)
> 	at org.apache.felix.scr.impl.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:616)
> 	at org.apache.felix.scr.impl.AbstractComponentManager.dispose(AbstractComponentManager.java:272)
> 	at org.apache.felix.scr.impl.ImmediateComponentManager.dispose(ImmediateComponentManager.java:120)
> 	at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:258)
> 	at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:264)
> 	at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:177)
> 	at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:690)
> 	at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:619)
> 	at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:532)
> 	at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3601)
> 	at org.apache.felix.framework.Felix._stopBundle(Felix.java:1989)
> 	at org.apache.felix.framework.Felix.stopBundle(Felix.java:1954)
> 	at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:3972)
> 	at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3257)
> 	at org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:259)
> 	at java.lang.Thread.run(Thread.java:613)
> ---- thread dump excerpt ----
> The problem is that on the one hand we need some kind of synchronization inside SCR and on the other hand SCR has a synchronous bundle listener. This is used to hear about started bundles and bundles about to stop (which is the case in the PackageAdmin thread dump above). Since synchronous listeners are called synchronously while the framework is trying to change the bundle state, the framework bundle locks are held while the listener is called.
> To prevent this kind of deadlock the bundle listener should probably dispose off the components asynchronously while the framework is stopping the bundles.
> Looking at when components are being disabled, we find four situations:
> (1) A bundle is stopped and its components must be disposed off. This may be done in the SCR thread asynchronous to the actual bundle stop processing.
> (2) A factory configuration object of a ComponentFactory instance is deleted. This may also be done asynchronously because IMHO it is not time critical to dispose off an instance of a ComponentFactory in this situation.
> (3) A ComponentInstance explicitly disposed of by calling the ComponentInstance.dispose() method. This request must also be acted upon immediately and the component disposed off synchronously.
> (4) The Declarative Services bundle is stopped. Here we have to immediately dispose off all components in the system. We cannot do this asynchronously.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.