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/04/08 09:35:30 UTC

Re: [healthcheck] Equivalent of SystemReady service?

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 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
> > 
> >