[jboss-jira] [JBoss JIRA] (AS7-5365) Intermittent failure due to missing OSGi service

[Thomas Diesler (JIRA)]

     [ https://issues.jboss.org/browse/AS7-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated AS7-5365:
--------------------------------

    Description: 
For the first OSGi related deployments we intermittently see 

{quote}
JBAS015870: Deploy of deployment "webapp.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jbosgi.integration.PersistentBundles.INSTALL Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"webapp.war\".REGISTER Missing[JBAS014861: <one or more transitive dependencies>]"]}
{quote}

which is due to a race condition at subsystem startup.

h4. Background

At startup the framework goes through various phases

# Framework.CREATE
# Framework.INIT
# Framework.ACTIVE

During framework INIT persistent bundles (i.e. from a former run) are installed/started according to their persistent settings.

In terms of services it means that the Framework.INIT service may depend on a number of Bundle.INSTALLED or Bundle.ACTIVE services. This however cannot be modelled as service dependencies because it must be possible to uninstall a persistent bundle (i.e. remove the Bundle.INSTALL) service without taking the framework down.

Currently, we use a ServiceListener for the persistent Bundle services and install a PersistentBundles.COMPLETE service that Framework.INIT can actually depend on. 

There is currently no guarantee that the PersistentBundles.COMPLETE service gets installed (and as a consequence that the Framework.INIT starts up) before the OSGi deployment does its phase checking for missing services.

AFAICS, there is currently no way to model this type of dependency properly without having this race condition.

A possible solution may be a notion of DependencyType.WEAK. The semantic would be a required dependency that can go away once the target service has reached its target state (or has failed)

h4. Example

* serviceA depends on serviceB with DependencyType.WEAK
* serviceA starts when serviceB has started
* serviceA stays UP when serviceB gets removed


  was:
For the first OSGi related deployments we intermittently see 

{code}
JBAS015870: Deploy of deployment "webapp.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jbosgi.integration.PersistentBundles.INSTALL Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"webapp.war\".REGISTER Missing[JBAS014861: <one or more transitive dependencies>]"]}
{code}

which is due to a race condition at subsystem startup.

h4. Background

At startup the framework goes through various phases

# Framework.CREATE
# Framework.INIT
# Framework.ACTIVE

During framework INIT persistent bundles (i.e. from a former run) are installed/started according to their persistent settings.

In terms of services it means that the Framework.INIT service may depend on a number of Bundle.INSTALLED or Bundle.ACTIVE services. This however cannot be modelled as service dependencies because it must be possible to uninstall a persistent bundle (i.e. remove the Bundle.INSTALL) service without taking the framework down.

Currently, we use a ServiceListener for the persistent Bundle services and install a PersistentBundles.COMPLETE service that Framework.INIT can actually depend on. 

There is currently no guarantee that the PersistentBundles.COMPLETE service gets installed (and as a consequence that the Framework.INIT starts up) before the OSGi deployment does its phase checking for missing services.

AFAICS, there is currently no way to model this type of dependency properly without having this race condition.

A possible solution may be a notion of DependencyType.WEAK. The semantic would be a required dependency that can go away once the target service has reached its target state (or has failed)

h4. Example

* serviceA depends on serviceB with DependencyType.WEAK
* serviceA starts when serviceB has started
* serviceA stays UP when serviceB gets removed



    
> Intermittent failure due to missing OSGi service
> ------------------------------------------------
>
>                 Key: AS7-5365
>                 URL: https://issues.jboss.org/browse/AS7-5365
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi, Server
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.2.0.CR1
>
>
> For the first OSGi related deployments we intermittently see 
> {quote}
> JBAS015870: Deploy of deployment "webapp.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jbosgi.integration.PersistentBundles.INSTALL Missing[JBAS014861: <one or more transitive dependencies>]","jboss.deployment.unit.\"webapp.war\".REGISTER Missing[JBAS014861: <one or more transitive dependencies>]"]}
> {quote}
> which is due to a race condition at subsystem startup.
> h4. Background
> At startup the framework goes through various phases
> # Framework.CREATE
> # Framework.INIT
> # Framework.ACTIVE
> During framework INIT persistent bundles (i.e. from a former run) are installed/started according to their persistent settings.
> In terms of services it means that the Framework.INIT service may depend on a number of Bundle.INSTALLED or Bundle.ACTIVE services. This however cannot be modelled as service dependencies because it must be possible to uninstall a persistent bundle (i.e. remove the Bundle.INSTALL) service without taking the framework down.
> Currently, we use a ServiceListener for the persistent Bundle services and install a PersistentBundles.COMPLETE service that Framework.INIT can actually depend on. 
> There is currently no guarantee that the PersistentBundles.COMPLETE service gets installed (and as a consequence that the Framework.INIT starts up) before the OSGi deployment does its phase checking for missing services.
> AFAICS, there is currently no way to model this type of dependency properly without having this race condition.
> A possible solution may be a notion of DependencyType.WEAK. The semantic would be a required dependency that can go away once the target service has reached its target state (or has failed)
> h4. Example
> * serviceA depends on serviceB with DependencyType.WEAK
> * serviceA starts when serviceB has started
> * serviceA stays UP when serviceB gets removed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira