[
https://issues.apache.org/jira/browse/ARIES-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18023476#comment-18023476
]
Stephan Siano commented on ARIES-2193:
--------------------------------------
Thanks for looking into this.
We add Spring, CXF and Camel as separate bundles with bundle:install (not via
the standard features) but the other features are correct (we do have the
aries-blueprint, subsystems, eclipselink, and transaction features active
together with Spring 5), so this setup should be close enough.
[~abhinav55]: Do you have an actual way to reproduce this issue or is this only
happening very sporadically?
> Blueprint Event Dispatcher Stuck Indefinitely
> ---------------------------------------------
>
> Key: ARIES-2193
> URL: https://issues.apache.org/jira/browse/ARIES-2193
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
> Reporter: Abhinav Dudeja
> Priority: Critical
>
> Hi Team,
> We use Apache Aries for bundle startup in karaf runtime. We recently have
> seen an issue where blueprint event dispatcher is stuck indefinitely waiting
> for task completion.
> "FelixFrameworkWiring" #26 daemon prio=5 os_prio=0 cpu=18820.30ms
> elapsed=416939.05s allocated=1707081728 B (1628 MB) defined_classes=415
> tid=0x00007f18615e37a0 nid=0x27ff15 waiting on condition [0x00007f181d0ed000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
> - parking to wait for <0x00000006dc002b88> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos([email protected]/LockSupport.java:252)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos([email protected]/AbstractQueuedSynchronizer.java:1679)
> at
> java.util.concurrent.LinkedBlockingQueue.poll([email protected]/LinkedBlockingQueue.java:460)
> at
> java.util.concurrent.ExecutorCompletionService.poll([email protected]/ExecutorCompletionService.java:209)
> at
> java.util.concurrent.AbstractExecutorService.doInvokeAny([email protected]/AbstractExecutorService.java:193)
> at
> java.util.concurrent.AbstractExecutorService.invokeAny([email protected]/AbstractExecutorService.java:235)
> at
> org.apache.aries.blueprint.utils.threading.ScheduledExecutorServiceWrapper$4.call(ScheduledExecutorServiceWrapper.java:185)
> at
> org.apache.aries.blueprint.utils.threading.ScheduledExecutorServiceWrapper$15.call(ScheduledExecutorServiceWrapper.java:446)
> at
> org.apache.aries.blueprint.utils.threading.RWLock.runReadOperation(RWLock.java:33)
> at
> org.apache.aries.blueprint.utils.threading.ScheduledExecutorServiceWrapper.runUnlessShutdown(ScheduledExecutorServiceWrapper.java:443)
> at
> org.apache.aries.blueprint.utils.threading.ScheduledExecutorServiceWrapper.invokeAny(ScheduledExecutorServiceWrapper.java:180)
> at
> org.apache.aries.blueprint.container.BlueprintEventDispatcher.callListener(BlueprintEventDispatcher.java:195)
> at
> org.apache.aries.blueprint.container.BlueprintEventDispatcher.sendInitialEvents(BlueprintEventDispatcher.java:119)
> at
> org.apache.aries.blueprint.container.BlueprintEventDispatcher.access$100(BlueprintEventDispatcher.java:62)
> at
> org.apache.aries.blueprint.container.BlueprintEventDispatcher$2.addingService(BlueprintEventDispatcher.java:98)
> - locked <0x00000004c4be16b0> (a java.util.concurrent.CopyOnWriteArraySet)
> at
> org.apache.aries.blueprint.container.BlueprintEventDispatcher$2.addingService(BlueprintEventDispatcher.java:93)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:943)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:871)
> at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:903)
> at
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> at
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4863)
> at org.apache.felix.framework.Felix.registerService(Felix.java:3834)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:328)
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:335)
> at
> org.apache.camel.blueprint.BlueprintCamelContext.doBuild(BlueprintCamelContext.java:121)
> at org.apache.camel.support.service.BaseService.build(BaseService.java:63)
> - locked <0x00000004ceee89b8> (a java.lang.Object)
> To confirm issue is not with ScheduledExecutorService, we passed a infinite
> loop with a 60 second timeout to the service and the service timed out as
> expected. But, when using the apache aries to submit a task, the thread is
> stuck indefinitely waiting for task completion.
> We use the default 60 second timeout set in the Aries library for
> ScheduledExecutorServiceWrapper.invokeAny().
> Please check this issue on priority as this causes the whole system to be
> stuck and needing a complete restart.
> Thanks,
> Abhinav Dudeja
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
