karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Tran <dant...@gmail.com>
Subject Re: Issues with latest Karaf 2.3.1
Date Wed, 06 Mar 2013 16:15:35 GMT
Nicolas,

You can set the start level at your bundle settings under its karaf's
feature descriptor

-D

On Wed, Mar 6, 2013 at 7:58 AM, Dan Tran <dantran@gmail.com> wrote:
> I think you are seeing
> https://issues.apache.org/jira/browse/KARAF-2189, also could you try
> to the mention work around?
>
> On your side, I also see all bundle using the same start level, you
> need to tune it so that service does not shutdown at the same time
> where one needs the other's services at shutdown.
>
> -D
>
> On Wed, Mar 6, 2013 at 2:29 AM, Achim Nierbeck <bcanhome@googlemail.com> wrote:
>> Hi Nicolas,
>>
>> that's some better information :)
>> I think I've seen a mail-thread talking of a similar situation.
>> It could well be that the blueprint extender is already down while your
>> application bundle is still trying to shutdown.
>> AFAIRC there is a workaround for this to decrease the startlevel of the
>> blueprint bundles.
>> This way it might be possible to work around this.
>>
>> regards, Achim
>>
>>
>> 2013/3/6 djos06 <djos06@gmail.com>
>>>
>>> Hi Everyone,
>>>
>>> Thanks for your answers.
>>>
>>> For more information I'm using blueprint and yes I have specials in
>>> destroy
>>> methods.
>>> I've tried to put try{} catch(Throwable t){} in destroy methods but the
>>> problem is still there.
>>> i've reduced the number of my active bundles to 2, to make the
>>> investigation
>>> of this problem more easy.
>>> Last time I've stopped karaf with shutdown command, and i saw an exception
>>> into my new try catch() in destroy method of one of my 2 active bundles.
>>>
>>> *org.osgi.service.blueprint.container.ServiceUnavailableException: The
>>> Blueprint container is being or has been destroyed:
>>> (objectClass=com.swingws.shaft.core.api.facade.RepositoryService)
>>>         at
>>>
>>> org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:233)
>>>         at
>>>
>>> org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:54)
>>>         at
>>>
>>> org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:291)
>>>         at Proxye8d4f95a_b29b_42dd_a38a_363d39688d30.getModel(Unknown
>>> Source)
>>>         at
>>>
>>> com.swingws.shaft.command.impl.dao.PavConnectionService.stop(PavConnectionService.java:151)
>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)[:1.6.0_24]
>>>         at
>>>
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.6.0_24]
>>>         at
>>>
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.6.0_24]
>>>         at java.lang.reflect.Method.invoke(Method.java:616)[:1.6.0_24]
>>>         at
>>>
>>> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:863)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:320)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:709)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:908)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:857)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:284)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.6.0_24]
>>>         at
>>>
>>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.6.0_24]
>>>         at
>>> java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.6.0_24]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:305)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BlueprintExtender.stop(BlueprintExtender.java:156)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:199)[7:org.apache.aries.blueprint.core:1.1.0]
>>>         at
>>>
>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[11:org.apache.aries.util:1.1.0]
>>>         at
>>>
>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[11:org.apache.aries.util:1.1.0]
>>>         at
>>>
>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[11:org.apache.aries.util:1.1.0]
>>>         at
>>>
>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[11:org.apache.aries.util:1.1.0]
>>>         at
>>>
>>> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[11:org.apache.aries.util:1.1.0]
>>>         at
>>>
>>> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.0.3.jar:]
>>>         at
>>>
>>> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)[org.apache.felix.framework-4.0.3.jar:]
>>>         at
>>>
>>> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)[org.apache.felix.framework-4.0.3.jar:]
>>>         at
>>>
>>> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)[org.apache.felix.framework-4.0.3.jar:]
>>>         at
>>>
>>> org.apache.felix.framework.Felix.stopBundle(Felix.java:2351)[org.apache.felix.framework-4.0.3.jar:]
>>>         at
>>>
>>> org.apache.felix.framework.Felix$2.run(Felix.java:882)[org.apache.felix.framework-4.0.3.jar:]
>>>         at java.lang.Thread.run(Thread.java:679)[:1.6.0_24]*
>>>
>>> Karaf has stopped well.
>>> But when I restart, the other one bundle (not the one which raised the
>>> exception in destroy method) was stucked in 'stopping' state and never has
>>> been started...
>>>
>>> I've looked with eclipse remote debugger, and it seems there is a thread
>>> which is waiting something forever, it seems to be related with the
>>> 'stopping' state, i've take a screenshot :
>>>
>>> <http://karaf.922171.n3.nabble.com/file/n4028028/screenEclipseKaraf.jpg>
>>>
>>> any idea ?
>>>
>>> Thanks,
>>>
>>> Nicolas
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022p4028028.html
>>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>>
>>
>>
>> --
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
>> Commiter & Project Lead
>> blog <http://notizblog.nierbeck.de/>

Mime
View raw message