[
https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910379#comment-13910379
]
metatech commented on FELIX-3067:
---------------------------------
Here is another instance of deadlock, between Blueprint and Felix :
{code}
"FelixPackageAdmin" daemon prio=6 tid=0x000000000988d800 nid=0x908 waiting for
monitor entry [0x000000000b94e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:816)
------> Trying to get Blueprint lock
- waiting to lock <0x00000000c195e9a8> (a
java.util.concurrent.atomic.AtomicBoolean)
at
org.apache.aries.blueprint.container.BlueprintExtender.destroyContext(BlueprintExtender.java:250)
at
org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:242)
at
org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:438)
at
org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:453)
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:237)
at
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:413)
at
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3898)
at org.apache.felix.framework.Felix.stopBundle(Felix.java:2287)
at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4687)
------> Obtained Felix global lock
at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3718)
at
org.apache.felix.framework.PackageAdminImpl.run(PackageAdminImpl.java:365)
at java.lang.Thread.run(Thread.java:662)
"Blueprint Extender: 1" daemon prio=6 tid=0x0000000008af4800 nid=0x170c in
Object.wait() [0x000000000d45e000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
------> Trying to get Felix global lock
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5029)
- locked <0x00000000c141a0b8> (a [Ljava.lang.Object;)
at org.apache.felix.framework.Felix.access$600(Felix.java:79)
at
org.apache.felix.framework.Felix$StatefulResolver.resolve(Felix.java:4196)
at
org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1448)
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:759)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1807)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:670)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1673)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:909)
at
org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.findCompatibleNamespaceHandler(NamespaceHandlerRegistryImpl.java:576)
at
org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.<init>(NamespaceHandlerRegistryImpl.java:466)
at
org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getNamespaceHandlers(NamespaceHandlerRegistryImpl.java:232)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:256)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:230)
------> Obtained Blueprint lock
- locked <0x00000000c195e9a8> (a
java.util.concurrent.atomic.AtomicBoolean)
- locked <0x00000000c195e998> (a
java.util.concurrent.atomic.AtomicBoolean)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{code}
> Prevent Deadlock Situation in Felix.acquireGlobalLock
> -----------------------------------------------------
>
> Key: FELIX-3067
> URL: https://issues.apache.org/jira/browse/FELIX-3067
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Affects Versions: framework-3.0.7, framework-3.0.8, framework-3.0.9,
> framework-3.2.0, framework-3.2.1, fileinstall-3.1.10
> Reporter: Felix Meschberger
> Attachments: FELIX-3067-sling.patch, FELIX-3067.patch,
> threaddump-ise-deadlock.txt, threads_locked_by_camel_type_converter
>
>
> Every now and then we encounter deadlock situations which involve the
> Felix.acquireGlobalLock method. In our use case we have the following aspects
> which contribute to this:
> (a) The Apache Felix Declarative Services implementation stops components
> (and thus causes service unregistration) while the bundle lock is being held
> because this happens in a SynchronousBundleListener while handling the
> STOPPING bundle event. We have to do this to ensure the bundle is not really
> stopped yet to properly stop the bundle's components.
> (b) Implementing a special class loader which involves dynamically resolving
> packages which in turn uses the global lock
> (c) Eclipse Gemini Blueprint implementation which operates asynchronously
> (d) synchronization in application classes
> Often times, I would assume that we can self-heal such complex deadlck
> situations, if we let acquireGlobalLock time out. Looking at the calles of
> acquireGlobalLock there seems to already be provision to handle this case
> since acquireGlobalLock returns true only if the global lock has actually
> been acquired.
> This issue is kind of a companion to FELIX-3000 where deadlocks involve
> sending service registration events while holding the bundle lock.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
