Hi Georg. How would Healthy, Unhealthy work? More specifically the latter. You have a reference to this marker service which gets registered and unregistered at what point in time, based on what condition?
I'll have a look at the code, but wanted to get your thoughts to begin with. Andrei On Sat, 28 Mar 2020 at 02:10, Georg Henzler <[email protected]> wrote: > Hi all, > > so regarding this [1] I figured that we also need a mechanism to > regularly trigger health checks so the service interface(s) can be > registered/unregistered - for this the idea is to introduce a > HealthCheckMonitor [2]. For the service marker interfaces I chose > Healthy, Unhealthy (that can be used with a target filter to select > relevant tags) and SystemReady (a shortcut, see [3]) as it is a > very prominent case. All this will AFAICT work well with the new > Condition service - it's just an additional property to services > Healthy/Unhealthy, also those interfaces can extend the Condition > interface once it's available. > > See [4] for the PR. Feedback welcome, in particular around the > naming of interfaces and the HealthCheckMonitor. > > Best Regards > Georg > > [1] https://issues.apache.org/jira/browse/FELIX-6245 > [2] https://issues.apache.org/jira/browse/FELIX-6250 > > [3] > @Reference > SystemReady systemReady; > // is shortcut for > @Reference(target="(tag=systemready)") > Healthy healthy; > > [4] https://github.com/apache/felix-dev/pull/12/files > > > On 2020-03-19 15:36, Robert Munteanu wrote: > > On Thu, 2020-03-19 at 14:47 +0100, Andrei Dulvac wrote: > >> Awesome, Ray, thanks for sharing. > >> > >> On Thu, 19 Mar 2020 at 14:36, Georg Henzler <[email protected]> > >> wrote: > >> > >> > Hi, > >> > > >> > so currently this is not yet possible, but it should be easy enough > >> > to > >> > get there. > >> > I created the issue [1] for this. Thanks Raymond for the link to > >> > the > >> > Condition > >> > Service Draft RFC, I have to read this in detail first but I think > >> > that > >> > should not > >> > be too hard to implement it in this direction to be prepared once > >> > this > >> > is final. > > > > Thanks all. So I guess for now I have to live with systemready support > > only. > > > > For background, I am using the SystemReady marker service to determine > > when an application has started and compute some metrics. > > > > I am 'weakly binding' to system ready by just a servicetracker for the > > SystemReady interface, without actually importing the classes. The > > reason is that I want my bundle to start ASAP and start tracking > > events. > > > > Tyring something more specific for healtchecks would be hard without > > actually binding to the code, so I'll pass on that. > > > > Thanks, > > Robert > > > >> > > >> > Best Regards > >> > -Georg > >> > > >> > [1] https://issues.apache.org/jira/browse/FELIX-6245 > >> > > >> > > >> > On 2020-03-19 14:15, Raymond Auge wrote: > >> > > Hey guys, I know this is likely premature for what you need, but > >> > > I > >> > > wanted > >> > > to also point you to the OSGi Condition Service RFC [1] which > >> > > attempts > >> > > to > >> > > address exactly these types of scenarios. > >> > > > >> > > [1] > >> > > > >> > > https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf > >> > > Sincerely, > >> > > - Ray > >> > > > >> > > On Thu, Mar 19, 2020 at 8:48 AM Andrei Dulvac <[email protected]> > >> > > wrote: > >> > > > >> > > > Hi Robert. > >> > > > > >> > > > Apologies for the long delay. > >> > > > > >> > > > I had a look as well as the Felix HCs and AFAICT there is no > >> > > > such > >> > > > "marker" > >> > > > service registered that you can listen for. The original design > >> > > > for > >> > > > HCs was > >> > > > not for readiness, but for more generic checks. > >> > > > You might be stuck with a listener of sorts on all checks using > >> > > > this > >> > > > tag: > >> > > > > >> > > > > >> > > https://github.com/apache/felix-dev/blob/master/healthcheck/generalchecks/src/main/java/org/apache/felix/hc/generalchecks/FrameworkStartCheck.java#L46 > >> > > > Maybe Georg can help with more clear instructions. > >> > > > > >> > > > We should also add a systemready tag to the Felix HCs. > >> > > > > >> > > > Personally, I think we need to have systemready implemented > >> > > > with HCs > >> > > > but > >> > > > keep the current API or merge the two properly. > >> > > > > >> > > > Sorry I couldn't be more helpful. > >> > > > - Andrei > >> > > > > >> > > > On Fri, Mar 13, 2020 at 6:47 PM Robert Munteanu < > >> > > > [email protected]> > >> > > > wrote: > >> > > > > >> > > > > Hi, > >> > > > > > >> > > > > I am using the old systemready bundle and I configured a > >> > > > > component to > >> > > > > react a component when the system ready by reacting when the > >> > > > > SystemReady service becomes available. > >> > > > > > >> > > > > How can I do the same with the new healtchecks bundle? I > >> > > > > tried the > >> > > > > README [1] and the migration guide [2] but got no ideas. > >> > > > > > >> > > > > BTW, the page at [3] points to a missing README file. > >> > > > > > >> > > > > Thanks, > >> > > > > Robert > >> > > > > > >> > > > > [1]: > >> > > > > https://github.com/apache/felix-dev/blob/master/healthcheck/README.md > >> > > > > [2]: > >> > > > > > >> > > https://sling.apache.org/documentation/bundles/sling-health-check-tool.html > >> > > > > [3]: > >> > > > > > >> > > http://felix.apache.org/documentation/subprojects/apache-felix-healthchecks.html > >> > > > > > >> > > > > ----------------------------------------------------------- > >> > > > > ---------- > >> > > > > To unsubscribe, e-mail: [email protected] > >> > > > > For additional commands, e-mail: [email protected] > >> > > > > > >> > > > > > >> > > >> > ----------------------------------------------------------------- > >> > ---- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: [email protected] > >> > > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] >
