Uninstalling stuff at jcrinstall startup

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Uninstalling stuff at jcrinstall startup

Bertrand Delacretaz
Hi,

In some cases, jcrinstall needs to uninstall bundles right after its
activate() method is called, for example when finding out that a
bundle that it installed is gone from the repository.

In testing on a system with about 50 bundles, with jcrinstall
uninstalling all of them (which is wrong, but showed the problem ;-) I
got the stack trace shown below at least once.

IIUC there's a conflict between the Felix SCR Component Actor trying
to do stuff with bundles, and jcrinstall doing the same.

Is there a clean way of handling this problem, does the OSGi framework
provide a locking mechanism when dealing with install/uninstall calls?

-Bertrand


Stack trace:

16.09.2008 15:59:37.321 *ERROR* [RepositoryObserver_1221573551897]
org.apache.sling.i18n
[org.apache.sling.i18n.impl.JcrResourceBundleProvider]
BundleComponentActivator : Exception invalidating
(java.lang.IllegalStateException: Cannot get Service Registration,
owned by Thread[SCR Component Actor,5,main])
java.lang.IllegalStateException: Cannot get Service Registration,
owned by Thread[SCR Component Actor,5,main]
        at org.apache.felix.scr.impl.AbstractComponentManager.lockServiceRegistration(AbstractComponentManager.java:782)
        at org.apache.felix.scr.impl.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:709)
        at org.apache.felix.scr.impl.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:549)
        at org.apache.felix.scr.impl.AbstractComponentManager.disableInternal(AbstractComponentManager.java:579)
        at org.apache.felix.scr.impl.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:616)
        at org.apache.felix.scr.impl.AbstractComponentManager.dispose(AbstractComponentManager.java:272)
        at org.apache.felix.scr.impl.ImmediateComponentManager.dispose(ImmediateComponentManager.java:120)
        at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:258)
        at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:264)
        at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:177)
        at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:690)
        at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:619)
        at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:532)
        at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3601)
        at org.apache.felix.framework.Felix._stopBundle(Felix.java:1989)
        at org.apache.felix.framework.Felix.stopBundle(Felix.java:1954)
        at org.apache.felix.framework.Felix._uninstallBundle(Felix.java:2108)
        at org.apache.felix.framework.Felix.uninstallBundle(Felix.java:2078)
        at org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:415)
        at org.apache.sling.jcr.jcrinstall.osgi.impl.BundleResourceProcessor.uninstall(BundleResourceProcessor.java:108)
        at org.apache.sling.jcr.jcrinstall.osgi.impl.OsgiControllerImpl.uninstall(OsgiControllerImpl.java:128)
        at org.apache.sling.jcr.jcrinstall.jcr.impl.RepositoryObserver.handleInitialUninstalls(RepositoryObserver.java:253)
        at org.apache.sling.jcr.jcrinstall.jcr.impl.RepositoryObserver.run(RepositoryObserver.java:281

Reply | Threaded
Open this post in threaded view
|

Re: Uninstalling stuff at jcrinstall startup

Felix Meschberger-2
Hi,

Bertrand Delacretaz schrieb:
> Hi,
>
> In some cases, jcrinstall needs to uninstall bundles right after its
> activate() method is called, for example when finding out that a
> bundle that it installed is gone from the repository.

Whose "activate()" method ? Do you mean, right after starting a bundle,
it should immediately be uninstalled again ?

>
> In testing on a system with about 50 bundles, with jcrinstall
> uninstalling all of them (which is wrong, but showed the problem ;-) I
> got the stack trace shown below at least once.
>
> IIUC there's a conflict between the Felix SCR Component Actor trying
> to do stuff with bundles, and jcrinstall doing the same.

Actually the "conflict" is between the components being started and the
bundle being stopped at the same time. This is a seldom but possible
situation in any life OSGi system.

>
> Is there a clean way of handling this problem, does the OSGi framework
> provide a locking mechanism when dealing with install/uninstall calls?

There might be two cases: If you remove the bundle immediately after
activating it, I would try to delay such removals.

If you try to remove the bundle, during the activating of the JCRInstall
bundle (or immediately after that), you might in the system startup
situation. In this case, I suggest you do the following: Register a
FrameworkListener and only consider installation tasks after the
FrameworkEvent.STARTED event has been received.

You can find out, whether the framework is starting up (and a
FrameworkListener is needed) by checking the state of the system bundle
(bundle 0): The system bundle only changes its state to started if the
framework has completed startup.

Hope this helps.

Regards
Felix

>
> -Bertrand
>
>
> Stack trace:
>
> 16.09.2008 15:59:37.321 *ERROR* [RepositoryObserver_1221573551897]
> org.apache.sling.i18n
> [org.apache.sling.i18n.impl.JcrResourceBundleProvider]
> BundleComponentActivator : Exception invalidating
> (java.lang.IllegalStateException: Cannot get Service Registration,
> owned by Thread[SCR Component Actor,5,main])
> java.lang.IllegalStateException: Cannot get Service Registration,
> owned by Thread[SCR Component Actor,5,main]
>         at org.apache.felix.scr.impl.AbstractComponentManager.lockServiceRegistration(AbstractComponentManager.java:782)
>         at org.apache.felix.scr.impl.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:709)
>         at org.apache.felix.scr.impl.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:549)
>         at org.apache.felix.scr.impl.AbstractComponentManager.disableInternal(AbstractComponentManager.java:579)
>         at org.apache.felix.scr.impl.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:616)
>         at org.apache.felix.scr.impl.AbstractComponentManager.dispose(AbstractComponentManager.java:272)
>         at org.apache.felix.scr.impl.ImmediateComponentManager.dispose(ImmediateComponentManager.java:120)
>         at org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:258)
>         at org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:264)
>         at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:177)
>         at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:690)
>         at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:619)
>         at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:532)
>         at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3601)
>         at org.apache.felix.framework.Felix._stopBundle(Felix.java:1989)
>         at org.apache.felix.framework.Felix.stopBundle(Felix.java:1954)
>         at org.apache.felix.framework.Felix._uninstallBundle(Felix.java:2108)
>         at org.apache.felix.framework.Felix.uninstallBundle(Felix.java:2078)
>         at org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:415)
>         at org.apache.sling.jcr.jcrinstall.osgi.impl.BundleResourceProcessor.uninstall(BundleResourceProcessor.java:108)
>         at org.apache.sling.jcr.jcrinstall.osgi.impl.OsgiControllerImpl.uninstall(OsgiControllerImpl.java:128)
>         at org.apache.sling.jcr.jcrinstall.jcr.impl.RepositoryObserver.handleInitialUninstalls(RepositoryObserver.java:253)
>         at org.apache.sling.jcr.jcrinstall.jcr.impl.RepositoryObserver.run(RepositoryObserver.java:281
>

Reply | Threaded
Open this post in threaded view
|

Re: Uninstalling stuff at jcrinstall startup

Bertrand Delacretaz
Hi Felix,

On Wed, Sep 17, 2008 at 10:09 AM, Felix Meschberger <[hidden email]> wrote:
> Bertrand Delacretaz schrieb:
>>... In some cases, jcrinstall needs to uninstall bundles right after its
>> activate() method is called, for example when finding out that a
>> bundle that it installed is gone from the repository.
>
> Whose "activate()" method ? Do you mean, right after starting a bundle,
> it should immediately be uninstalled again ?

No, that's right after the jcrinstall's activate() method is called.
Jcrinstall starts a thread which immediately starts uninstalling other
bundles, if they are not found in the repository anymore.

>>... IIUC there's a conflict between the Felix SCR Component Actor trying
>> to do stuff with bundles, and jcrinstall doing the same.
>
> Actually the "conflict" is between the components being started and the
> bundle being stopped at the same time. This is a seldom but possible
> situation in any life OSGi system....

Ok, confirms my suspicion. If that happens, the best might be to retry
the uninstall call a bit later?

> ...If you try to remove the bundle, during the activating of the JCRInstall
> bundle (or immediately after that), you might in the system startup
> situation. In this case, I suggest you do the following: Register a
> FrameworkListener and only consider installation tasks after the
> FrameworkEvent.STARTED event has been received...

I'll try that, thanks for the suggestion.

> ...You can find out, whether the framework is starting up (and a
> FrameworkListener is needed) by checking the state of the system bundle
> (bundle 0): The system bundle only changes its state to started if the
> framework has completed startup....

Ok, will try (https://issues.apache.org/jira/browse/SLING-660)

-Bertrand

Reply | Threaded
Open this post in threaded view
|

Re: Uninstalling stuff at jcrinstall startup

Felix Meschberger-2
Hi,

Bertrand Delacretaz schrieb:

> On Wed, Sep 17, 2008 at 10:09 AM, Felix Meschberger <[hidden email]> wrote:
>> ...If you try to remove the bundle, during the activating of the JCRInstall
>> bundle (or immediately after that), you might in the system startup
>> situation. In this case, I suggest you do the following: Register a
>> FrameworkListener and only consider installation tasks after the
>> FrameworkEvent.STARTED event has been received...
>
> I'll try that, thanks for the suggestion.
>
>> ...You can find out, whether the framework is starting up (and a
>> FrameworkListener is needed) by checking the state of the system bundle
>> (bundle 0): The system bundle only changes its state to started if the
>> framework has completed startup....
>
> Ok, will try (https://issues.apache.org/jira/browse/SLING-660)


Actually it may really be a good idea any way to only start with the
real work after the framework has finished its startup procedure.

Regards
Felix