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 > >> > -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
