[ 
https://issues.apache.org/jira/browse/ARIES-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18020732#comment-18020732
 ] 

Dominik Przybysz commented on ARIES-2193:
-----------------------------------------

[~abhinav55] Thank you for the reported issue,
could you share the versions of blueprint bundles, karaf, camel and whatever 
other bundle that may affect the startup?
Also some detailed startup logs can be helpful.
Are you able to provide a test or a configured environment sample where the 
issue may be reproduced?

{quote}We recently have seen an issue where blueprint event dispatcher is stuck 
indefinitely waiting for task completion.{quote}

Could you narrow what has changed that blueprint container started stucking in 
your environment? I understand that initially it was working without problems.

> 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)

Reply via email to