[jira] [Commented] (ARIES-1430) Blueprint bundle shut down after timeout even if all dependencies are present at that time

["Guillaume Nodet (JIRA)" <ji...@apache.org>]

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