On Thu, 2015-12-03 at 13:55 +0100, Julian Sedding wrote: > I like several ideas of the approach suggested by Robert. > > Before going into the technical details, however, I am wondering > who's > responsibility it is to decide whether the system is ready. > - Is it the sum of all components that declare themselves ready? > - Or is it an administrator's task to define a list of services that > need to be ready before the system can be considered ready?
I think this would be up to the system administrator, as that's the person who knows when the system is ready. Taking the Sling launchpad example, we probably could use the following initial checks: - HTTP service is available - Sling repository is available We can also extend the model to contain: - A number of health checks pass ( which can also be designed as a service being available ) - intial content from the org.apache.sling.launchpad.content is installed ( same as above, can also be designed as a service ) Robert > > Regards > Julian > > On Thu, Dec 3, 2015 at 11:58 AM, Robert Munteanu <romb...@apache.org> > wrote: > > On Thu, 2015-12-03 at 11:04 +0100, Bertrand Delacretaz wrote: > > > Hi, > > > > > > This old and fun topic again ;-) > > > > > > Quoting an interesting idea suggested by Carsten in SLING-5337 > > > > > > > ...To find out when the system is ready we could define a > > > > service > > > > interface > > > > with some properties, maybe a name property which holds the > > > > name of > > > > the application. When that application is started, this service > > > > is registered and other parties can listen for this ... > > > > > > Making our readiness detection more granular can be very useful, > > > and > > > I > > > think there's some parallels with the OSGi capabilities model. > > > > > > How about using a similar model for our readiness detection? > > > Capability names like the following come to mind to identify > > > various > > > stages of readiness: > > > > > > osgi.startup.done > > > sling.app.example.com.ready > > > healtchecks.startup.green > > > http.server.ready > > > osgi.subsystem.foo.ready > > > > I was thinking a bit about this recently and I also think we need a > > more granular approach. What I came up with is a decentralised > > approach: > > > > - an application being 'ready' is defined by a number of components > > being 'ready' > > - all components describe how to detect when they are ready > > - a ready service tracks these component descriptions and declares > > the > > application is ready when all the components are ready > > > > The controller will most likely be an OSGi service, and I am > > currently > > thinking about how to declare 'components'. The most flexible way > > would > > be to create an OSGi factory configurations, one per component. > > These > > configurations would then describe how to decide if a component is > > ready, e.g. here is a dummy configuration waiting for the HTTP > > service > > > > readyComponentName = Http Server > > readyComponentService = > > (objectClass=org.osgi.service.http.HttpService) > > > > Then the startup sequence would be the following: > > > > 1) The ReadyServiceImpl component gets instantiated, ideally at a > > very > > low start level > > 2) The ReadyServiceImpl picks up all configurations and starts > > tracking > > all components which need to be declared 'ready' > > 3) Once all components are 'ready', the ReadyServiceImpl itself is > > also > > ready, possibly firing an OSGi event > > > > If we stick to OSGi services, we get all the benefits of the > > dynamic > > nature of services, and the system can regress from ready to not > > ready > > if a required service goes away. > > > > Thoughts? > > > > Robert
