You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by djos06 <dj...@gmail.com> on 2013/03/05 11:37:31 UTC
Issues with latest Karaf 2.3.1
Hi,
I was hoping that the latest version of Karaf could correct my bug but it
doesn't.
I explain myself :
Sometimes, I try to shutdown karaf properly via stop script and most of the
times it never succeed to stop it, so i have to kill karaf process.
When I start karaf again, my bundles doesn't starts, there is always one
bundle which is stopping and others are in grace period or creating. And it
is sucked like this...
It seems karaf keep bundle state for some of them but not all, especially
for the one which is 'stopping'.
Do you know what is the problem here ?
is there a way to correct it ?
is it a bug of karaf ?
Thanks
Nicolas
--
View this message in context: http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Issues with latest Karaf 2.3.1
Posted by djos06 <dj...@gmail.com>.
Just for information,
I re-installed karaf 2.2.5, and I don't have any problem with it, all is
working fine.
Nicolas
--
View this message in context: http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022p4028070.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Issues with latest Karaf 2.3.1
Posted by djos06 <dj...@gmail.com>.
it doesn't change anything for me,
For info I put the new file called
'org.apache.aries.blueprint.core-1.1.1.jar' into
karaf/system/org/apache/aries/blueprint/org.apache.aries.blueprint.core/1.1.0
and renamed it to ...1.1.0.jar
I tried with and without defining start-levels for my bundles. ( i've done
it in startup.properties)
I've noticed something weird too : when i start karaf after a shutdown and I
see a bundle which is in 'stopping' state , exactly 5 minutes after it
succeed to stop, and one another bundle change its state to 'stopping',...
... it continue to do it for all bundles and if you wait a very long time
(more than 1 hour) that all plugins stopped one after one, they all restart
well and passed to 'created' ..
Nicolas
--
View this message in context: http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022p4028059.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Issues with latest Karaf 2.3.1
Posted by Achim Nierbeck <bc...@googlemail.com>.
Looks like the latest SNAPSHOT of Aries fixes this issue.
@Nicolas, you might also check if it works for you as it did for Dan :)
regards, Achim
2013/3/6 Dan Tran <da...@gmail.com>
> You may want to invest time to get
> feature-maven-plugin/karaf-maven-plugin to do this work for you. It
> is worthwhile for big app.
>
> I, personally, dont know how to configure startLevel from bundle
> perspective. My be the webconsole can help.
>
> -D
>
> On Wed, Mar 6, 2013 at 8:35 AM, djos06 <dj...@gmail.com> wrote:
> > We actually don't use feature descriptor, we just put our bundles .jar
> into
> > deploy/ directory,
> > is there a way to declare the bundle's start-level into a file contained
> in
> > the .jar of the bundle ?
> >
> >
> >
> >
> > --
> > View this message in context:
> http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022p4028035.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/>
Re: Issues with latest Karaf 2.3.1
Posted by Dan Tran <da...@gmail.com>.
You may want to invest time to get
feature-maven-plugin/karaf-maven-plugin to do this work for you. It
is worthwhile for big app.
I, personally, dont know how to configure startLevel from bundle
perspective. My be the webconsole can help.
-D
On Wed, Mar 6, 2013 at 8:35 AM, djos06 <dj...@gmail.com> wrote:
> We actually don't use feature descriptor, we just put our bundles .jar into
> deploy/ directory,
> is there a way to declare the bundle's start-level into a file contained in
> the .jar of the bundle ?
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022p4028035.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Issues with latest Karaf 2.3.1
Posted by djos06 <dj...@gmail.com>.
We actually don't use feature descriptor, we just put our bundles .jar into
deploy/ directory,
is there a way to declare the bundle's start-level into a file contained in
the .jar of the bundle ?
--
View this message in context: http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022p4028035.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Issues with latest Karaf 2.3.1
Posted by Dan Tran <da...@gmail.com>.
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 <da...@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 <bc...@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 <dj...@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/>
Re: Issues with latest Karaf 2.3.1
Posted by Dan Tran <da...@gmail.com>.
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 <bc...@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 <dj...@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/>
Re: Issues with latest Karaf 2.3.1
Posted by djos06 <dj...@gmail.com>.
Hi Achim,
Do you mean i have to reduce the *karaf.startlevel.bundle* into*
etc/config.properties* ?
The current value is set to *80*.
What is the consequences of that modification and what value to set ?
I don't understand why i would have to reduce this value because it's the
default karaf value.
Thanks,
Nicolas
--
View this message in context: http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022p4028032.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Issues with latest Karaf 2.3.1
Posted by Dan Tran <da...@gmail.com>.
I think you are seeing
https://issues.apache.org/jira/browse/KARAF-2189, also could you try
the mention work around? it does not work for me either
On you 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 service.
-D
On Wed, Mar 6, 2013 at 2:29 AM, Achim Nierbeck <bc...@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 <dj...@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/>
Re: Issues with latest Karaf 2.3.1
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <dj...@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/>
Re: Issues with latest Karaf 2.3.1
Posted by djos06 <dj...@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.
Re: Issues with latest Karaf 2.3.1
Posted by Achim Nierbeck <bc...@googlemail.com>.
Without knowing much about your application (you didn't tell much about the
way it's set-up), but my gut-feeling tells me it's your bundle that's
buggy.
How does it work, is it using a Activator? Do you do some special handling
in the stop method?
Or do you use blueprint.
I'd say try to strip down your application to a minimum to find the issue.
regards, Achim
2013/3/5 djos06 <dj...@gmail.com>
> Hi,
>
> I was hoping that the latest version of Karaf could correct my bug but it
> doesn't.
> I explain myself :
>
> Sometimes, I try to shutdown karaf properly via stop script and most of the
> times it never succeed to stop it, so i have to kill karaf process.
> When I start karaf again, my bundles doesn't starts, there is always one
> bundle which is stopping and others are in grace period or creating. And it
> is sucked like this...
> It seems karaf keep bundle state for some of them but not all, especially
> for the one which is 'stopping'.
>
> Do you know what is the problem here ?
> is there a way to correct it ?
> is it a bug of karaf ?
>
> Thanks
> Nicolas
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022.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/>
Re: Issues with latest Karaf 2.3.1
Posted by Ryan Moquin <fr...@gmail.com>.
Have you tried connecting via visualvm and seeing what the threads are
waiting on with a thread dump? There are some tools that can help you to
read the dump, I think Thread Dump Analyzer has visualvm plugins.
Ryan
On Mar 5, 2013 3:47 PM, "Christian Schneider" <ch...@die-schneider.net>
wrote:
> I also had the problem that karaf can take a long time to shut down. Till
> now I have not digged deeper into the problem.
> Typicall it happens if an Activator does not return when stopping a
> bundle. This can have a lot of reasons though.
>
> Any ideas how to debug this?
> Perhaps we could support this by printing the bundles that can not be
> stopped in the log.
>
> I also can reproduce the problem that when karaf is killed not all bundles
> come back up again. I guess the state of the bundles is persisted and
> reflects the status when karaf was killed.
>
> Christian
>
> Am 05.03.2013 11:37, schrieb djos06:
>
>> Hi,
>>
>> I was hoping that the latest version of Karaf could correct my bug but it
>> doesn't.
>> I explain myself :
>>
>> Sometimes, I try to shutdown karaf properly via stop script and most of
>> the
>> times it never succeed to stop it, so i have to kill karaf process.
>> When I start karaf again, my bundles doesn't starts, there is always one
>> bundle which is stopping and others are in grace period or creating. And
>> it
>> is sucked like this...
>> It seems karaf keep bundle state for some of them but not all, especially
>> for the one which is 'stopping'.
>>
>> Do you know what is the problem here ?
>> is there a way to correct it ?
>> is it a bug of karaf ?
>>
>> Thanks
>> Nicolas
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.**
>> com/Issues-with-latest-Karaf-**2-3-1-tp4028022.html<http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022.html>
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>
Re: Issues with latest Karaf 2.3.1
Posted by Christian Schneider <ch...@die-schneider.net>.
I also had the problem that karaf can take a long time to shut down.
Till now I have not digged deeper into the problem.
Typicall it happens if an Activator does not return when stopping a
bundle. This can have a lot of reasons though.
Any ideas how to debug this?
Perhaps we could support this by printing the bundles that can not be
stopped in the log.
I also can reproduce the problem that when karaf is killed not all
bundles come back up again. I guess the state of the bundles is
persisted and
reflects the status when karaf was killed.
Christian
Am 05.03.2013 11:37, schrieb djos06:
> Hi,
>
> I was hoping that the latest version of Karaf could correct my bug but it
> doesn't.
> I explain myself :
>
> Sometimes, I try to shutdown karaf properly via stop script and most of the
> times it never succeed to stop it, so i have to kill karaf process.
> When I start karaf again, my bundles doesn't starts, there is always one
> bundle which is stopping and others are in grace period or creating. And it
> is sucked like this...
> It seems karaf keep bundle state for some of them but not all, especially
> for the one which is 'stopping'.
>
> Do you know what is the problem here ?
> is there a way to correct it ?
> is it a bug of karaf ?
>
> Thanks
> Nicolas
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Issues with latest Karaf 2.3.1
Posted by Ryan Moquin <fr...@gmail.com>.
I think if a bundle fails to start correctly, Karaf remembers that on next
startup (I think, for some reason I thought I noticed that). Regardless,
if one of your bundles is being stopped, then it probably errored out and
maybe it's managed to clog up a thread karaf has to wait on to terminate.
You really need to see if there are any errors in your log, or dump the
thread states and look for a thread that references your code.... that
might help.
Ryan
On Mar 5, 2013 5:37 AM, "djos06" <dj...@gmail.com> wrote:
> Hi,
>
> I was hoping that the latest version of Karaf could correct my bug but it
> doesn't.
> I explain myself :
>
> Sometimes, I try to shutdown karaf properly via stop script and most of the
> times it never succeed to stop it, so i have to kill karaf process.
> When I start karaf again, my bundles doesn't starts, there is always one
> bundle which is stopping and others are in grace period or creating. And it
> is sucked like this...
> It seems karaf keep bundle state for some of them but not all, especially
> for the one which is 'stopping'.
>
> Do you know what is the problem here ?
> is there a way to correct it ?
> is it a bug of karaf ?
>
> Thanks
> Nicolas
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Issues-with-latest-Karaf-2-3-1-tp4028022.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>