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?
Regards Julian On Thu, Dec 3, 2015 at 11:58 AM, Robert Munteanu <[email protected]> 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
