[
https://issues.apache.org/jira/browse/ARIES-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998466#comment-14998466
]
Guillaume Nodet commented on ARIES-1430:
----------------------------------------
I don't think this is caused by the processor.
The only way I can see that happen is if a namespace handler is unregistered
while the blueprint container is waiting for a service dependency.
> Blueprint bundle shut down after timeout even if all dependencies are present
> at that time
> ------------------------------------------------------------------------------------------
>
> Key: ARIES-1430
> URL: https://issues.apache.org/jira/browse/ARIES-1430
> Project: Aries
> Issue Type: Bug
> Components: Blueprint
> Affects Versions: blueprint-core-1.4.4
> Reporter: Christian Schneider
> Assignee: Christian Schneider
> Priority: Critical
> Fix For: blueprint-core-1.4.5
>
>
> When I run the jpa blueprint example it works fine at the start but after 4
> minutes I see the exception below.
> When the blueprint context is created the future for the timeout of
> dependencies is canceled.
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L379
> In Aries JPA I use a ComponentDefinitionRegistryProcessor to scan for the
> @PersistenceContext annoations and register a service reference for these. I
> think that this triggers
> the future for the timeout of such dependencies again. If this processor is
> called after the future is canceled above then the future will not be
> canceled anymore. So after the timeout (5min) it will
> trigger and stop the blueprintcontainer even if all dependencies are
> satisfied now.
> This is the code that is executed after the timeout:
> https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/container/BlueprintContainerImpl.java#L341
> It matches the exception and explains why there are no unresolved
> dependencies.
> I would be happy about feedback from anyone with deeper blueprint knowledge.
> Is what I do there in Aries JPA incorrect? If yes then we need a new Aries
> JPA release .. though I am not sure how to better address the problem.
> If it is correct then we need to fix this in blueprint core.
> A simple fix/workaround would be to check if there are no unresolved
> dependencies when the future times out and not stop the container in this
> case. A better fix would cancel the future as soon as all dependencies are
> fulfilled.
> 2015-10-11 19:08:43,371 | ERROR | rint Extender: 2 | BlueprintContainerImpl
> | 12 - org.apache.aries.blueprint.core - 1.4.4 | Unable to start
> blueprint container for bundle
> net.lr.tasklist.cdi.tasklist-persistence/1.0.0.SNAPSHOT due to unresolved
> dependencies []
> java.util.concurrent.TimeoutException
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:336)[12:org.apache.aries.blueprint.core:1.4.4]
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[12:org.apache.aries.blueprint.core:1.4.4]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_60]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_60]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
