Hi Georg, Some more debug showed me that the cause for ServiceUnavailableFilter not picking up is due to the osgi.http.whiteboard.filter.regex that I use. At some point, jetty is building the filter chain to process the request and the ServiceUnavailableFilter is drop from the chain because the regex is pass as is to jetty's FilterMapping as a pattern to compare with the request path, but the compare does not use regex to match the pattern with the path. Here is the screenshot: [image: image.png]As far as I know, standard servlet filter does not allow using regex to match path so my guess is that the value of osgi.http.whiteboard.filter.regex service property from OSGI http whiteboard spec need to be converted into path specs by the whiteboard implementation (paxweb in my case) before passing it to jetty to check if the filter should process the request. Am i right?
Thai On Wed, Aug 14, 2019 at 2:49 PM Nhut Thai Le <[email protected]> wrote: > 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. > -- 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.
