karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [VOTE] Apache Karaf 4.0.2 release
Date Mon, 12 Oct 2015 08:51:12 GMT
I'd rather keep this vote open as it seems like to be a corner case which
can be addressed with a 4.0.3 which we can shortly after the aries bug in
JPA is fixed.

regards, Achim


2015-10-11 21:10 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

> By the way, I upgraded to new Blueprint release for 4.0.2 (as it fixed
> couple of "important" issues). I will take a look and a diff between the
> two versions.
>
> Regards
> JB
>
> On 10/11/2015 08:18 PM, Christian Schneider wrote:
>
>> 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
>>>>
>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message