I think that I found the problem.
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.
In any case I propose we cancel the release and try to include a fix in
karaf 4.0.2. So I revert my vote to
-1 (non binding)
Christian
On 11.10.2015 19:24, Christian Schneider wrote:
I just did some more testing and found a problem.
When I run my tasklist-blueprint-cdi example it works fine at the
start but after some time I see this exception:
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]
After this the tasklist-persistence bundle does not work anymore. If
this does not only happen with my example then it would be a pretty
critical bug.
I am not yet sure what the reason is but I will dig some more. I think
the problem could be either in blueprint core or in blueprint jpa.
If you want to test yourself you should use the branch jpa-2.1.0 (old
name ... it uses jpa 2.2.0 now).
https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-blueprint-cdi
Christian
On 11.10.2015 16:53, Christian Schneider wrote:
+1 (non binding)
Tested my blueprint and DS examples (jpa,transaction, hibernate,
cxf, jaxrs-connector)
Looks all good.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
