Thank you for your suggestion Georg, To address the issue of healthcheck start at level 4 instead of 3 as desired, here are what i have tried: Make sure the autoDisableFilter is false osgi.http.whiteboard.filter.regex=(?!/system/).* osgi.http.whiteboard.context.select=(osgi.http.whiteboard.context.name =WebviewerServletContextHelper) tags=systemalive responseTextFor503=Service Unavailable, wait.. wait... wait.... service.ranking=1 avoid404DuringStartup=true autoDisableFilter=false
I also tried setting service.ranking to 10000, but it does not change anything Enabling debug log show me these lines: 12:19:02.697 [ConfigurationListener Event Queue] DEBUG o.a.f.h.c.i.f.ServiceUnavailableFilter - Reloading HC references for tags [systemalive] 12:19:02.699 [ConfigurationListener Event Queue] DEBUG o.a.f.h.c.i.f.ServiceUnavailableFilter - Found 2 health check service references for tags [systemalive] 12:19:02.700 [ConfigurationListener Event Queue] DEBUG o.a.f.h.c.i.f.ServiceUnavailableFilter - Registered ServiceUnavailableFilter for tags [systemalive] 12:19:02.701 [ConfigurationListener Event Queue] INFO o.a.f.h.c.i.f.ServiceUnavailableFilter - ServiceUnavailableFilter active (start level 4) There is no other log from ServiceUnavailableFilter, and my breakpoint in the doFilter of this servlet was never got hit. Checking the imports of the healthcheck bundles, i found they require some packages from slf4j, lang3, pax-web-api, javax.servlet and osgi.service.component so i also changed the start level of these bundles to the same level as healthcheck but ServiceUnavailableFilter still report start level 4. One question here is that once i start playing around with start level i realize that I may need to set start level for a lot of infrastructure bundles (jetty, paxweb, logging, ...) to be earlier than business logic bundles, is it normal since i remember reading somewhere that i should let the framework resolve the bundle dependencies through their manifest ? Thai On Tue, Aug 13, 2019 at 6:44 PM Georg Henzler <[email protected]> wrote: > Hi Thai, > > it's not easy to see what your problem is here, you will have to do some > more debugging. I have some pointers though... > > > I set service.ranking=1 because i'm running pax-web and it seems to > > execute > > filters in ascending ranking. > > "Higher rankings will be placed first in the chain, that is, filter > chains are sorted in descending order." > from [1] > > > ... I also set avoid404DuringStartup=true and > > start level of healthcheck.core to level 3 (default is 4) because I > > want > > this filter to be up before my servlets and filters (default level 4). > > However, I always see "INFO o.a.f.h.c.i.f.ServiceUnavailableFilter - > > ServiceUnavailableFilter active (start level 4)" > > the log says it started at start level 4, so somehow the configuration > you made for start level 3 did not work > > > 1. In a dynamic env like osgi container, how can we be sure that a > > request > > always be processed by a filter before arriving at the servlet? Bundles > > do > > not always start in the same order thus a filter may be registered > > after > > the servlet it supposed to protect > > use start levels to ensure filters are started before the servlets (I > think you are already trying to do this) > > > 2. Even when i waited for a long period after starting my server and > > healthcheck return OK for all of my checks, why does > > ServiceUnavailableFilter not handle any request? > > If the health check returns OK the ServiceUnavailableFilter is not meant > to kick in. Activate debug logging [2] to see if the filter is doing > anything. Also ensure you left config property 'autoDisableFilter' to > default 'false'. > > -Georg > > [1] > > https://felix.apache.org/documentation/subprojects/apache-felix-http-service.html#filter-service-properties > [2] > > https://github.com/apache/felix/blob/fd76982e887e82159288f1d0c1908402885d8e4c/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L288 > > https://github.com/apache/felix/blob/fd76982e887e82159288f1d0c1908402885d8e4c/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L264 > > > > > -- Castor Technologies Inc 460 rue St-Catherine St Ouest, Suite 613 Montréal, Québec H3B-1A7 (514) 360-7208 o (514) 798-2044 f [email protected] www.castortech.com CONFIDENTIALITY NOTICE: The information contained in this e-mail is confidential and may be proprietary information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any viewing, dissemination, distribution, disclosure, copy or use of the information contained in this e-mail message is strictly prohibited. If you have received and/or are viewing this e-mail in error, please immediately notify the sender by reply e-mail, and delete it from your system without reading, forwarding, copying or saving in any manner. Thank you. AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est confidentiel, peut être protégé par le secret professionnel et est réservé à l'usage exclusif du destinataire. Toute autre personne est par les présentes avisée qu'il lui est strictement interdit de diffuser, distribuer ou reproduire ce message. Si vous avez reçu cette communication par erreur, veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.
