You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Georg Henzler <fe...@ghenzler.de> on 2020/03/28 01:09:47 UTC

Re: [healthcheck] Equivalent of SystemReady service?

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 <fe...@ghenzler.de>
>> 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 <du...@apache.org>
>> > > 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 <
>> > > > rombert@apache.org>
>> > > > 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: users-unsubscribe@felix.apache.org
>> > > > > For additional commands, e-mail: users-help@felix.apache.org
>> > > > >
>> > > > >
>> >
>> > -----------------------------------------------------------------
>> > ----
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> >
>> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

Re: [healthcheck] Equivalent of SystemReady service?

Posted by Robert Munteanu <ro...@apache.org>.
Hi Georg,

On Mon, 2020-06-29 at 17:57 +0200, Georg Henzler wrote:
> Hi Robert,
> 
> 
> 
> sorry for the delay, but now I'm back on to this and after polishing,
> 
> I'm planning to release everything within the next two weeks.

That would be great, thanks!

> 
> > 4. I was also surprised that I needed to create an executor for the
> > 'Healthy' event to be registered. I thought that with the
> > eventadmin
> > requirement the services would be registered automatically, without
> > me
> > intervening.
> 
> 
> So no instance of HealthCheckMonitor is active by default currently.
> 
> Configuring one means that the tags as given will be regularly
> 
> executed. To be exactly in line with systemready, you would configure
> 
> an instance of HealthCheckMonitor with tag "systemready" and
> 
> intervalInSec=5. Would you have expected that this config is done
> 
> automatically for the case the event admin is present? (we
> 
> definitely cannot start monitors for all checks by default, that
> 
> would potentially be harmful)

Hm, so by definition no checks are executed, even though they are
defined? Then probably it does not make sense to execute some of them
by default. I though that they would be executed by default once
registered.
> 
> 
> 
> > 3. I was a bit surprised that hc.core requires the Servlet API. The
> > systemready bundle was a bit more lightweight.
> 
> 
> systemready had the same dependency, just optional. I created
> 
> FELIX-6289 to make it also optional for hc.core.

Great, thanks,

> 
> 
> 
> > 2. core build fails with pax-exam tests. Perhaps related to Java
> > 11?
> 
> 
> I checked this, it is indeed a Java 11 problem (just checked both
> 
> 1.8 and 11). I'll check and fix.

Ack.

> 
> 
> 
> > 1. api build fails due to the baselining check
> 
> 
> this I could not reproduce.

It only happens on Java 11, and it looks like a false positive.

[INFO] -----------------------------------------------------------------------------------------------------------
[INFO] * org.apache.felix.hc.api.execution                  changed    2.0.0      2.0.0      2.0.1      Version increase required
[INFO]      ~ class org.apache.felix.hc.api.execution.HealthCheckSelector
[INFO]          ~ method hashCode()
[INFO]              - annotated jdk.internal.HotSpotIntrinsicCandidate
[INFO] -----------------------------------------------------------------------------------------------------------
[ERROR] org.apache.felix.hc.api.execution: Version increase required; detected 2.0.0, suggested 2.0.1

Not sure if there is anything to be done here. See also 
https://github.com/bndtools/bnd/issues/2177 for context.

Thanks,
Robert


Re: [healthcheck] Equivalent of SystemReady service?

Posted by Georg Henzler <gh...@apache.org>.
Hi Robert,

sorry for the delay, but now I'm back on to this and after polishing,
I'm planning to release everything within the next two weeks.

> 4. I was also surprised that I needed to create an executor for the
> 'Healthy' event to be registered. I thought that with the eventadmin
> requirement the services would be registered automatically, without me
> intervening.

So no instance of HealthCheckMonitor is active by default currently.
Configuring one means that the tags as given will be regularly
executed. To be exactly in line with systemready, you would configure
an instance of HealthCheckMonitor with tag "systemready" and
intervalInSec=5. Would you have expected that this config is done
automatically for the case the event admin is present? (we
definitely cannot start monitors for all checks by default, that
would potentially be harmful)

> 3. I was a bit surprised that hc.core requires the Servlet API. The
> systemready bundle was a bit more lightweight.

systemready had the same dependency, just optional. I created
FELIX-6289 to make it also optional for hc.core.

> 2. core build fails with pax-exam tests. Perhaps related to Java 11?

I checked this, it is indeed a Java 11 problem (just checked both
1.8 and 11). I'll check and fix.

> 1. api build fails due to the baselining check

this I could not reproduce.

-Georg


On 2020-04-21 13:53, Robert Munteanu wrote:
> Hello Georg,
> 
> Thanks for the implementation, looks good! I took it for a spin and for
> my scenario it works as expected.
> 
> In addition to that. I have some notes that you may find useful.
> 
> 1. api build fails due to the baselining check -
> org.apache.felix.hc.api.execution: Version increase required; detected
> 2.0.0, suggested 2.0.1 .
> 
> 2. core build fails with pax-exam tests. Perhaps related to Java 11?
> 
> ERROR: Bundle org.apache.felix.http.whiteboard [25] Error starting
> file:/tmp/1587396148625-0/pax-exam-
> downloads/org.apache.felix.http.whiteboard_4.0.0.jar
> (org.osgi.framework.BundleException: Unable to resolve
> org.apache.felix.http.whiteboard [25](R 25.0): missing requirement
> [org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!
> (version>=2.0.0))) [caused by: Unable to resolve
> org.apache.felix.http.jetty [24](R 24.0): missing requirement
> [org.apache.felix.http.jetty [24](R 24.0)] osgi.wiring.package;
> (osgi.wiring.package=javax.annotation)] Unresolved requirements:
> [[org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!
> (version>=2.0.0)))])
> org.osgi.framework.BundleException: Unable to resolve
> org.apache.felix.http.whiteboard [25](R 25.0): missing requirement
> [org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!
> (version>=2.0.0))) [caused by: Unable to resolve
> org.apache.felix.http.jetty [24](R 24.0): missing requirement
> [org.apache.felix.http.jetty [24](R 24.0)] osgi.wiring.package;
> (osgi.wiring.package=javax.annotation)] Unresolved requirements:
> [[org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!
> (version>=2.0.0)))]
> 
> 3. I was a bit suprised that hc.core requires the Servlet API. The
> systemready bundle was a bit more lightweight.
> 
> 4. I was also suprised that I needed to create an executor for the
> 'Healthy' event to be registered. I thought that with the eventadmin
> requirement the services would be registered automatically, without me
> intervening.
> 
> Anyway, the implementation works for me and I can support both
> systemready and health checks, which is great.
> 
> Thanks!
> Robert
> 

Re: [healthcheck] Equivalent of SystemReady service?

Posted by Robert Munteanu <ro...@apache.org>.
Hello Georg,

Thanks for the implementation, looks good! I took it for a spin and for
my scenario it works as expected.

In addition to that. I have some notes that you may find useful.

1. api build fails due to the baselining check -
org.apache.felix.hc.api.execution: Version increase required; detected
2.0.0, suggested 2.0.1 .

2. core build fails with pax-exam tests. Perhaps related to Java 11?

ERROR: Bundle org.apache.felix.http.whiteboard [25] Error starting
file:/tmp/1587396148625-0/pax-exam-
downloads/org.apache.felix.http.whiteboard_4.0.0.jar
(org.osgi.framework.BundleException: Unable to resolve
org.apache.felix.http.whiteboard [25](R 25.0): missing requirement
[org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!
(version>=2.0.0))) [caused by: Unable to resolve
org.apache.felix.http.jetty [24](R 24.0): missing requirement
[org.apache.felix.http.jetty [24](R 24.0)] osgi.wiring.package;
(osgi.wiring.package=javax.annotation)] Unresolved requirements:
[[org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!
(version>=2.0.0)))])
org.osgi.framework.BundleException: Unable to resolve
org.apache.felix.http.whiteboard [25](R 25.0): missing requirement
[org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!
(version>=2.0.0))) [caused by: Unable to resolve
org.apache.felix.http.jetty [24](R 24.0): missing requirement
[org.apache.felix.http.jetty [24](R 24.0)] osgi.wiring.package;
(osgi.wiring.package=javax.annotation)] Unresolved requirements:
[[org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!
(version>=2.0.0)))]

3. I was a bit suprised that hc.core requires the Servlet API. The
systemready bundle was a bit more lightweight.

4. I was also suprised that I needed to create an executor for the
'Healthy' event to be registered. I thought that with the eventadmin
requirement the services would be registered automatically, without me
intervening.

Anyway, the implementation works for me and I can support both
systemready and health checks, which is great.

Thanks!
Robert

On Wed, 2020-04-08 at 11:35 +0200, Georg Henzler wrote:
> Hi all,
> 
> so I went ahead with this, see documentation [5] on how it works. Any
> feedback is appreciated (best before the release :))
> 
> -Georg
> 
> 
> [5] 
> https://github.com/apache/felix-dev/blob/master/healthcheck/README.md#monitoring-health-checks
> 
> 
> On 2020-03-28 23:31, Georg Henzler wrote:
> > Hi Andrei,
> > 
> > so the marker service SystemReady is intended to be used in the
> > exact 
> > same
> > way as the one from systemready bundle [1] (and reacts fix to the 
> > health
> > status of tag 'systemready'). Healthy is the more generic marker 
> > interface,
> > it allows to depend on the healthy status (that is OK or WARN, see
> > [2] 
> > for
> > reasoning) of any tag, see [3] for an example. Now a prerequisite
> > for 
> > this
> > to work is that the status is regularly polled, this is what the
> > HealthCheckMonitor [4] is for (FELIX-6250)
> > 
> > The Unhealthy marker interface is just the opposite, this could be 
> > useful
> > to activate an alternative fallback functionality or some self-
> > healing
> > mechanism. Now this will be the least-important use case I suppose,
> > but 
> > I
> > liked the idea to have a symmetric approach here.
> > HealthCheckMonitor 
> > [4]
> > allows to configure if Healthy and/or Unhealthy is registered upon 
> > status
> > changes of the health check (the default will only register
> > Healthy).
> > 
> > -Georg
> > 
> > [1]
> > https://github.com/apache/felix-dev/blob/master/systemready/src/main/java/org/apache/felix/systemready/SystemReady.java
> > [2]
> > https://github.com/apache/felix-dev/tree/master/healthcheck#semantic-meaning-of-health-check-results
> > [3]
> > @Reference(target="(tag=db-available)")
> > Healthy dbAvailable;
> > 
> > [4]
> > https://github.com/apache/felix-dev/blob/775545aa8f0657d7c5f703bc901693dcdbaff92f/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/monitor/HealthCheckMonitor.java#L108
> > 
> > 


Re: [healthcheck] Equivalent of SystemReady service?

Posted by Georg Henzler <fe...@ghenzler.de>.
Hi all,

so I went ahead with this, see documentation [5] on how it works. Any
feedback is appreciated (best before the release :))

-Georg


[5] 
https://github.com/apache/felix-dev/blob/master/healthcheck/README.md#monitoring-health-checks


On 2020-03-28 23:31, Georg Henzler wrote:
> Hi Andrei,
> 
> so the marker service SystemReady is intended to be used in the exact 
> same
> way as the one from systemready bundle [1] (and reacts fix to the 
> health
> status of tag 'systemready'). Healthy is the more generic marker 
> interface,
> it allows to depend on the healthy status (that is OK or WARN, see [2] 
> for
> reasoning) of any tag, see [3] for an example. Now a prerequisite for 
> this
> to work is that the status is regularly polled, this is what the
> HealthCheckMonitor [4] is for (FELIX-6250)
> 
> The Unhealthy marker interface is just the opposite, this could be 
> useful
> to activate an alternative fallback functionality or some self-healing
> mechanism. Now this will be the least-important use case I suppose, but 
> I
> liked the idea to have a symmetric approach here. HealthCheckMonitor 
> [4]
> allows to configure if Healthy and/or Unhealthy is registered upon 
> status
> changes of the health check (the default will only register Healthy).
> 
> -Georg
> 
> [1]
> https://github.com/apache/felix-dev/blob/master/systemready/src/main/java/org/apache/felix/systemready/SystemReady.java
> [2]
> https://github.com/apache/felix-dev/tree/master/healthcheck#semantic-meaning-of-health-check-results
> [3]
> @Reference(target="(tag=db-available)")
> Healthy dbAvailable;
> 
> [4]
> https://github.com/apache/felix-dev/blob/775545aa8f0657d7c5f703bc901693dcdbaff92f/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/monitor/HealthCheckMonitor.java#L108
> 
> 

Re: [healthcheck] Equivalent of SystemReady service?

Posted by Georg Henzler <fe...@ghenzler.de>.
Hi Andrei,

so the marker service SystemReady is intended to be used in the exact 
same
way as the one from systemready bundle [1] (and reacts fix to the health
status of tag 'systemready'). Healthy is the more generic marker 
interface,
it allows to depend on the healthy status (that is OK or WARN, see [2] 
for
reasoning) of any tag, see [3] for an example. Now a prerequisite for 
this
to work is that the status is regularly polled, this is what the
HealthCheckMonitor [4] is for (FELIX-6250)

The Unhealthy marker interface is just the opposite, this could be 
useful
to activate an alternative fallback functionality or some self-healing
mechanism. Now this will be the least-important use case I suppose, but 
I
liked the idea to have a symmetric approach here. HealthCheckMonitor [4]
allows to configure if Healthy and/or Unhealthy is registered upon 
status
changes of the health check (the default will only register Healthy).

-Georg

[1] 
https://github.com/apache/felix-dev/blob/master/systemready/src/main/java/org/apache/felix/systemready/SystemReady.java
[2] 
https://github.com/apache/felix-dev/tree/master/healthcheck#semantic-meaning-of-health-check-results
[3]
@Reference(target="(tag=db-available)")
Healthy dbAvailable;

[4] 
https://github.com/apache/felix-dev/blob/775545aa8f0657d7c5f703bc901693dcdbaff92f/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/monitor/HealthCheckMonitor.java#L108


On 2020-03-28 09:48, Andrei Dulvac wrote:
> 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 <fe...@ghenzler.de> 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 <fe...@ghenzler.de>
>> >> 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 <du...@apache.org>
>> >> > > 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 <
>> >> > > > rombert@apache.org>
>> >> > > > 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: users-unsubscribe@felix.apache.org
>> >> > > > > For additional commands, e-mail: users-help@felix.apache.org
>> >> > > > >
>> >> > > > >
>> >> >
>> >> > -----------------------------------------------------------------
>> >> > ----
>> >> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> > For additional commands, e-mail: users-help@felix.apache.org
>> >> >
>> >> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> > For additional commands, e-mail: users-help@felix.apache.org
>> 

Re: [healthcheck] Equivalent of SystemReady service?

Posted by Andrei Dulvac <du...@apache.org>.
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 <fe...@ghenzler.de> 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 <fe...@ghenzler.de>
> >> 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 <du...@apache.org>
> >> > > 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 <
> >> > > > rombert@apache.org>
> >> > > > 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: users-unsubscribe@felix.apache.org
> >> > > > > For additional commands, e-mail: users-help@felix.apache.org
> >> > > > >
> >> > > > >
> >> >
> >> > -----------------------------------------------------------------
> >> > ----
> >> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> > For additional commands, e-mail: users-help@felix.apache.org
> >> >
> >> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>