Hi Jörg,
there is the option "autoDisableFilter" [1] in the
ServiceUnavailableFilter - if true the filter automatically unregisters
itself upon first non-503 result. Once unregistered it listens to
FrameworkEvent.STARTLEVEL_CHANGED events to reregister once needed (the
shutdown case). During normal operations (that includes deployments that
might cause the selected "systemalive" checks to be temporarily
unavailable) the filter is not active (which is also good from a
performance perspective).
So really, all that would be needed to replace oas-startupfilter +
-disabler and oas-starter-startup is the simple config [2] in the
oas-starter provisioning model.
-Georg
[1]
https://github.com/apache/felix/blob/d5245ba3ba306b57b83c4d5c6cfe499d955b0acb/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L98
[2]
org.apache.felix.hc.core.impl.filter.ServiceUnavailableFilter
tags=["systemalive]
osgi.http.whiteboard.context.select="(&(osgi.http.whiteboard.context.name\=*)(!(osgi.http.whiteboard.context.name\=org.osgi.service.http)))"
osgi.http.whiteboard.filter.regex=".*"
autoDisableFilter=B"true"
On 2019-04-07 19:49, Jörg Hoh wrote:
Hi Georg,
Merging the 2 implementations oas-startupfilter + -disabler and
oas-starter-startup makes fully sense to me, although I am bit hesitant
by
replacing the basic approach.
these 2 have a rather static assumption, when the application is up,
and
their sole purpose is to indicate that. And once the system is up, it's
up
and this state remains unchanged until the startupfilterDisabler is
deactivated. A healthcheck based implementation can changed its mind
based
on many factors, you already mentioned the fact that key services
should be
available. If these services go down during runtime, the status of this
check changes.
If I understand you correctly, then the semantic of the startup itself
might not change, but it's more likely, that the unavailability of such
a
key service would cause the Filter to kick again, changing
runtime-behavior; currently it does not.
Is this intended?
Jörg
Am Sa., 6. Apr. 2019 um 00:24 Uhr schrieb Georg Henzler
<[email protected]
:
Hi all,
we have currently two mechanisms in Sling to wait for startup:
* sling-org-apache-sling-startupfilter +
sling-org-apache-sling-startupfilter-disabler
* sling-org-apache-sling-starter-startup (only used for the starter
application AFAIK)
Now that systemready in Felix is fully migrated to Felix Health Checks
I
would like to rely on ServiceUnavailableFilter [1] instead. The
advantage is that this filter can be configured in a declarative
fashion
(what is required to be alive can be configured, e.g. for a customer
project it's easy to wait for additional custom services) and 503 is
also correctly sent upon shutdown.
Is this approach something everyone is ok with?
-Georg
[1]
https://github.com/apache/felix/blob/trunk/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java
