So I'll move forward with this and I created [1] to track this change.
-Georg
[1] https://issues.apache.org/jira/browse/SLING-8418
On 2019-04-08 10:49, Jörg Hoh wrote:
Hi Georg,
ok, wasn't aware of the "100% compatibility mode" :-) So +1 from my
side.
Jörg
Am Mo., 8. Apr. 2019 um 00:28 Uhr schrieb Georg Henzler
<[email protected]
:
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
>>
