Ready Service

[bjhargrave]

Original bug ID: BZ#1699 From: @pkriens Reported version: R4 V4.2

[bjhargrave]

Comment author: @pkriens

Today it is possible to find out if the system is fully initialized by listening to the framework events. However, there are many use cases where a component does not want to be created until the framework has stabilized. Components are really good in waiting for services, and lousy at listening to framework events because that requires them to run.

I wonder if it would be useful to create a Ready service. This service would be registered by a bundle when the framework has initialized. The service should not require a specific interface but it would be useful to have properties for the startlevel and maybe some other aspects?

A simple Ready service implementation could just listen to the framework events but a more powerful implementation could also have a check for certain services to be present, and other constraints. The key abstraction I think that is needed is a service that bundles can depend on to signal when the system is ready.

Wdyt?

[bjhargrave]

Comment author: Richard Hall <heavy@ungoverned.org>

Seems somewhat odd to me. You're using services as an event listener mechanism.

[bjhargrave]

Comment author: @tjwatson

I agree with Richard.

I would like to get a better understanding on the requirements for such a service and how the current FrameworkEvents do not solve the requirements.

One issue I can see is that service events are synchronous while FrameworkEvents are async. This poses a bit of a race condition when trying to monitor start-level values. This ready service only has FrameworkEvents to use for the property values (unless we build this into core ;-). So the FrameworkEvent.STARTLEVEL_CHANGED will be listened for by the Ready service and perhaps some org.osgi.framework.startlevel service property would be set according to the current value of the framework start-level, but the problem is this value may already be stale if another start-level change is being done. I am only going into details on this issue because I have run into this race condition and I would like a solution to avoid it if possible. But I see no way to solve it without some new core functionality.

[bjhargrave]

Comment author: holger.hoffstatte@paremus.com

Another problem with the notion of "waiting for system stabilization" is the inherent danger of livelock, at least as long as "system" has an arbitrarily open scope.

[bjhargrave]

Comment author: Michael Keith <michael.keith@oracle.com>

This is one of the problems that I always hoped capabilities would solve.

[bjhargrave]

Comment author: @pkriens

Requirements Capabilities are currently defined static, they would not handle the dynamic system state.

Framework events are only one aspect of being ready (albeit an important one). You could define ready as: framework initialized and started all bundles, startlevel 5, 6 ExtensionXYZ services registered, firewall is up, etc. What ready means is up to the implementer of that service, it just aggregates what that deployer thinks it means to be ready.

Anyway, this is not supposed to be a Framework registered service. It is just a bundle registering it that has an understanding what Ready means.

The race condition is interesting but I think it is orthogonal on this issue.

[bjhargrave]

Comment author: Tim Diekmann <tdiekman@tibco.com>

While I certainly would like such a service (and sort of implemented one for my needs), I don't quite see the need for the involvement of the specification group. Wouldn't this be customer specific?

[bjhargrave]

Comment author: @bjhargrave

A big problem is that one bundle's idea of system ready is another bundle's idea of system not ready. I think it is really up to an "application" or "subsystem" to define system ready and establish a means of communicating that to it's constituent bundles. So within a given set of installed bundles, there may be multiple different views of system ready.

The framework provides the primitives (events) to track progress of the framework startup so someone can decide when their view of system ready is achieved.

[bjhargrave]

Comment author: Michael Keith <michael.keith@oracle.com>

Requirements Capabilities are currently defined static, they would not handle the dynamic system state.

Unfortunately that is what they became. They were at one point supposed to include "feature" requirements which were dynamic and part of the resolving process. (Features could come and go as the bundles that supported them did.) It would then have been a natural next step to define specific named features for different parts of the/a system.

[bjhargrave]

Comment author: Richard Hall <heavy@ungoverned.org>

They were at one point supposed to include "feature" requirements which were dynamic and part of the resolving process. (Features could come and go as the bundles that supported them did.) It would then have been a natural next step to define specific named features for different parts of the/a system.

That sounds a lot like a service! :-)

I don't recall ever thinking that generic capabilities/requirements would be dynamic like that; however, it might be possible to do something like that as a layer on top if we define a resolver API.

[bjhargrave]

Comment author: Richard Hall <heavy@ungoverned.org>

They were at one point supposed to include "feature" requirements which were dynamic and part of the resolving process. (Features could come and go as the bundles that supported them did.) It would then have been a natural next step to define specific named features for different parts of the/a system.

That sounds a lot like a service! :-)

I don't recall ever thinking that generic capabilities/requirements would be dynamic like that; however, it might be possible to do something like that as a layer on top if we define a resolver API.

Perhaps I misread your comment previously, but capabilities are dynamic with respect to bundles coming and going, otherwise it wouldn't make sense. However, they are not dynamic in the sense that a bundle couldn't say things like, "I provide this capability now" or "I no longer provide this capability" at run time.

However, I stand by my previous comment that something like this may be possible in a layer above.

[bjhargrave]

Comment author: Michael Keith <michael.keith@oracle.com>

Yeah, I must have been half asleep and misread Peter's reply earlier. I think he meant that he wanted it to be a dynamic service so that a consumer could start at some point in the future when all of the required system was ready. Capabilities would only provide this at resolve time and not when a missing bundle got installed/started later on.

[bjhargrave]

Comment author: Glyn Normington <gnormington@vmware.com>

I would say that "readiness" almost always corresponds to the availability of certain "key" services in the service registry. So it is possible for the system to become ready and very soon after become unready if such services are retracted from the service registry.

From this perspective, a ready service might be able to provide a standard way of waiting for, and obtaining, key services with an indication of the key services which cannot be published until the wait is satisfied. Key services would probably need to be named in some way so they could be referred to unambiguously before being published.

This would allow deadlocks among threads waiting for key services at least to be detected and perhaps even prevented (by throwing an exception from any wait which would deadlock).

[bjhargrave]

Comment author: @pkriens

In reply to BZ#7.

I do not think the bundle can define "ready", it is the deployer that defines what ready means. The current problem is that we do not have a standardized way that is easy to depend on that allows us to signal to reusable bundles what the deployer has in mind.

So yes, what ready means is flexible and should not be defined. How it is signalled to to bundles in a way that allows them to easy depend on this state is rather simply to define.

Event requirements and capabilities can be used to control this service.

[bjhargrave]

Comment author: @bjhargrave

CPEG mtg: We discussed this and agreed not to define a ready service since it is intrusive.

As an alternative, Peter will pursue an RFC for a change to DS to allow external configuration of component enablement. This would allow a deployer to configure some criteria that must be met before a component can be enabled.

Assigning to Peter.

[bjhargrave]

Comment author: @pkriens

Closing because I will not have time to do this any time soon