Return-Path: X-Original-To: apmail-aries-dev-archive@www.apache.org Delivered-To: apmail-aries-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 075D7106B7 for ; Wed, 11 Dec 2013 12:30:21 +0000 (UTC) Received: (qmail 3407 invoked by uid 500); 11 Dec 2013 12:30:20 -0000 Delivered-To: apmail-aries-dev-archive@aries.apache.org Received: (qmail 3173 invoked by uid 500); 11 Dec 2013 12:30:13 -0000 Mailing-List: contact dev-help@aries.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aries.apache.org Delivered-To: mailing list dev@aries.apache.org Received: (qmail 3035 invoked by uid 99); 11 Dec 2013 12:30:09 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Dec 2013 12:30:09 +0000 Date: Wed, 11 Dec 2013 12:30:09 +0000 (UTC) From: "Dmitry Konstantinov (JIRA)" To: dev@aries.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ARIES-1051) Blueprint deadlock is occured during Karaf startup or bundle update action MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ARIES-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13845347#comment-13845347 ] Dmitry Konstantinov commented on ARIES-1051: -------------------------------------------- ?? I'm not sure the problem comes only from the concurrency model in BlueprintContainerImpl. The second stack trace shows a logic problem as there's no reason why blueprint should cause a resolution of the bundle that is being extended, i.e. the concurrency model is written so that this should not occur (given stopping the bundle is waiting on the current run to finish, so the bundle should at least be in a stopping state). at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:102) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819) at org.apache.felix.framework.Felix.getBundleResource(Felix.java:1498) at org.apache.felix.framework.BundleImpl.getResource(BundleImpl.java:628) at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.(NamespaceHandlerRegistryImpl.java:507) ?? Bundle stopping is an external activity, in case of Karaf - FeatureService triggers refreshing operation for some bundles during features installation. Blueprint reacts on the activity and try to occure locks. May be Felix also adds some problems here by waiting without an exception in registerService method when another thread try to stop the same bundle. > Blueprint deadlock is occured during Karaf startup or bundle update action > -------------------------------------------------------------------------- > > Key: ARIES-1051 > URL: https://issues.apache.org/jira/browse/ARIES-1051 > Project: Aries > Issue Type: Bug > Components: Blueprint > Affects Versions: blueprint-core-1.1.0 > Environment: Windows 7, x64 > java version "1.6.0_24" > Java(TM) SE Runtime Environment (build 1.6.0_24-b07) > Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) > Karaf 2.3.1 > Reporter: Dmitry Konstantinov > Priority: Critical > > There are two locks - felix bundle lock and lock of {{AtomicBoolean scheduled}} in BlueprintContainerImpl class and these locks can be occured in diferent order for some situations. > For example: > 1) In case of container initialization the order is following: blueprint lock (inside executor task) -> bundle lock (inside service registration) > 2) In case of container destroying: bundle lock (bundle tracker) -> blueprint lock (BlueprintContainerImpl.namespaceHandlerUnregistered method) > The thread dump provides a real example of the deadlock: > {noformat} > "Blueprint Extender: 3" daemon prio=6 tid=0x0000000006ec4000 nid=0x1658 in Object.wait() [0x0000000009b2e000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0x00000000e098fdf0> (a [Ljava.lang.Object;) > at java.lang.Object.wait(Object.java:485) > at org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4871) > - locked <0x00000000e098fdf0> (a [Ljava.lang.Object;) > at org.apache.felix.framework.Felix.registerService(Felix.java:3205) > at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346) > at org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:439) > at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:379) > at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261) > - locked <0x00000000e0274b50> (a java.util.concurrent.atomic.AtomicBoolean) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106) > at org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > 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:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > "FelixFrameworkWiring" daemon prio=6 tid=0x0000000006eca000 nid=0x900 waiting for monitor entry [0x000000000b30e000] > java.lang.Thread.State: BLOCKED (on object monitor) > at org.apache.aries.blueprint.container.BlueprintContainerImpl.namespaceHandlerUnregistered(BlueprintContainerImpl.java:892) > - waiting to lock <0x00000000e0274b50> (a java.util.concurrent.atomic.AtomicBoolean) > at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.unregisterHandler(NamespaceHandlerRegistryImpl.java:582) > at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.unregisterHandler(NamespaceHandlerRegistryImpl.java:173) > at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.removedService(NamespaceHandlerRegistryImpl.java:144) > at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:956) > at org.osgi.util.tracker.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1) > at org.osgi.util.tracker.AbstractTracked.untrack(AbstractTracked.java:341) > at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:902) > at org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932) > at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793) > at org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543) > at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260) > at org.apache.felix.framework.Felix.access$000(Felix.java:74) > at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390) > at org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:148) > at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127) > at org.apache.aries.util.AriesFrameworkUtil.safeUnregisterService(AriesFrameworkUtil.java:114) > at org.apache.aries.blueprint.container.ServiceRecipe.unregister(ServiceRecipe.java:209) > at org.apache.aries.blueprint.container.BlueprintContainerImpl.unregisterServices(BlueprintContainerImpl.java:701) > at org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:907) > at org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:857) > at org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:284) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:305) > at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:206) > at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500) > at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433) > at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725) > at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463) > at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422) > at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103) > at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695) > at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483) > at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244) > at org.apache.felix.framework.Felix.stopBundle(Felix.java:2351) > at org.apache.felix.framework.Felix$RefreshHelper.stop(Felix.java:4629) > at org.apache.felix.framework.Felix.refreshPackages(Felix.java:3951) > at org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:172) > at java.lang.Thread.run(Thread.java:662) > {noformat} -- This message was sent by Atlassian JIRA (v6.1.4#6159)