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
