You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Nhut Thai Le <nt...@castortech.com> on 2019/08/13 21:03:08 UTC
healthcheck: ServiceUnavailableFilter does not kick-in
Hello,
I have about 30 servlet contexts (ServletContextHelper) scattered across
multiple bundles. One of these context (WebviewerServletContextHelper) has
"osgi.http.whiteboard.context.path=/".
I also have one bundle containing all servletFilters for these servlet
contexts. These filters mostly for session manipulation and security checks
so If the request does not pass through these filters, it will cause
exception when arriving at the servlet. Thus, i want to use
ServiceUnavailableFilter from healthcheck to make sure that my filters (and
other components) are ready before accepting http requests. I made the
config file for ServiceUnavailableFilter as follow:
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
I set service.ranking=1 because i'm running pax-web and it seems to execute
filters in ascending ranking. 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)" which indicates the
component has been activated but the ServiceUnavailableFilter never process
any request.
So here are some questions
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
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?
About my env, I'm using
org.apache.felix.healthcheck.annotation_2.0.0
org.apache.felix.healthcheck.api_2.0.0
org.apache.felix.healthcheck.core_2.0.6
org.apache.felix.healthcheck.generalchecks_2.0.4
and pax-web 7.2.4 in equinox (org.eclipse.osgi_3.12.0.v20170512-1932)
Hope someone can shed a light
Thai
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Carsten Ziegeler <cz...@apache.org>.
It's not even proprietary :) You can register servlet filters using the
whiteboard to contexts managed by the http service as noted in [1].
Carsten
Am 20.08.2019 um 06:53 schrieb Raymond Auge:
> By /system/ I guess you are referring to Felix webconsole?
>
> The section of the Http Whiteboard spec that seems relevant is this one [1]
>
> The issue is that the webconsole servlet is added via the legacy
> HttpService API. If you wish to filter such paths using Http Whiteboard you
> need to look into Felix's proprietary support for mapping Http Whiteboard
> Services to legacy Http Service contexts. I do believe Felix supports this
> but not sure it's documented.
>
> But Carsten would know!
>
> - Ray
>
> [1]
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.httpservice.integration
>
> On Tue, Aug 20, 2019 at 9:37 AM Nhut Thai Le <nt...@castortech.com> wrote:
>
>> I am using filter.pattern in the mean time but the annoying is that it does
>> not allow me to exclude requests for /system/
>>
>> I posted a question on paxweb , waiting for answer, will update this email
>> thread when i have some news
>>
>> Thanks you for the tips
>>
>> Thai
>>
>> On Fri, Aug 16, 2019 at 2:20 AM Georg Henzler <fe...@ghenzler.de> wrote:
>>
>>> Hi Thai,
>>>
>>>> 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?
>>>
>>> so osgi.http.whiteboard.filter.regex is standard [1], is this a bug in
>>> the
>>> whiteboard implementation paxweb then?
>>>
>>> you could also try to leave osgi.http.whiteboard.filter.regex out (as
>>> you
>>> select a specific context via osgi.http.whiteboard.context.select) or
>>> use osgi.http.whiteboard.filter.pattern instead (the properties of
>>> ServiceUnavailableFilter are passed one to one to
>>> ServiceUnavailableFilter,
>>> even if there will be a new one in the future you can just use it).
>>>
>>> -Georg
>>>
>>>
>>> [1]
>>>
>>>
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055
>>>
>>> On 2019-08-15 00:23, Nhut Thai Le wrote:
>>>> 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:
>>>>
>>>
>>>>
>>>> Thai
>>>>
>>>> On Wed, Aug 14, 2019 at 2:49 PM Nhut Thai Le <nt...@castortech.com>
>>>> 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
>>>>> [1]=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 <fe...@ghenzler.de>
>>>>> 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
>>>>> ntle@castortech.com
>>>>> www.castortech.com [2]
>>>>>
>>>>> 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
>>>> ntle@castortech.com
>>>> www.castortech.com [2]
>>>>
>>>> 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.
>>>>
>>>> Links:
>>>> ------
>>>> [1] http://osgi.http.whiteboard.context.name
>>>> [2] http://www.castortech.com
>>>
>>
>>
>> --
>> 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
>> ntle@castortech.com
>> 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.
>>
>
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Nhut Thai Le <nt...@castortech.com>.
hi Raymond,
One of he reason i want to use healthcheck is to be able to look at
/system/health, it should response even if other components being checked
are not ready. Thus, /system/health should be excluded from
ServiceUnavailableFilter. I dont have webconsole installed on my dev env at
the moment.
Thai
On Tue, Aug 20, 2019 at 9:53 AM Raymond Auge <ra...@liferay.com>
wrote:
> By /system/ I guess you are referring to Felix webconsole?
>
> The section of the Http Whiteboard spec that seems relevant is this one [1]
>
> The issue is that the webconsole servlet is added via the legacy
> HttpService API. If you wish to filter such paths using Http Whiteboard you
> need to look into Felix's proprietary support for mapping Http Whiteboard
> Services to legacy Http Service contexts. I do believe Felix supports this
> but not sure it's documented.
>
> But Carsten would know!
>
> - Ray
>
> [1]
>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.httpservice.integration
>
> On Tue, Aug 20, 2019 at 9:37 AM Nhut Thai Le <nt...@castortech.com> wrote:
>
> > I am using filter.pattern in the mean time but the annoying is that it
> does
> > not allow me to exclude requests for /system/
> >
> > I posted a question on paxweb , waiting for answer, will update this
> email
> > thread when i have some news
> >
> > Thanks you for the tips
> >
> > Thai
> >
> > On Fri, Aug 16, 2019 at 2:20 AM Georg Henzler <fe...@ghenzler.de> wrote:
> >
> > > Hi Thai,
> > >
> > > > 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?
> > >
> > > so osgi.http.whiteboard.filter.regex is standard [1], is this a bug in
> > > the
> > > whiteboard implementation paxweb then?
> > >
> > > you could also try to leave osgi.http.whiteboard.filter.regex out (as
> > > you
> > > select a specific context via osgi.http.whiteboard.context.select) or
> > > use osgi.http.whiteboard.filter.pattern instead (the properties of
> > > ServiceUnavailableFilter are passed one to one to
> > > ServiceUnavailableFilter,
> > > even if there will be a new one in the future you can just use it).
> > >
> > > -Georg
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055
> > >
> > > On 2019-08-15 00:23, Nhut Thai Le wrote:
> > > > 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:
> > > >
> > >
> > > >
> > > > Thai
> > > >
> > > > On Wed, Aug 14, 2019 at 2:49 PM Nhut Thai Le <nt...@castortech.com>
> > > > 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
> > > >> [1]=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 <fe...@ghenzler.de>
> > > >> 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
> > > >> ntle@castortech.com
> > > >> www.castortech.com [2]
> > > >>
> > > >> 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
> > > > ntle@castortech.com
> > > > www.castortech.com [2]
> > > >
> > > > 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.
> > > >
> > > > Links:
> > > > ------
> > > > [1] http://osgi.http.whiteboard.context.name
> > > > [2] http://www.castortech.com
> > >
> >
> >
> > --
> > 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
> > ntle@castortech.com
> > 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.
> >
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
>
--
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
ntle@castortech.com
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.
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Raymond Auge <ra...@liferay.com>.
By /system/ I guess you are referring to Felix webconsole?
The section of the Http Whiteboard spec that seems relevant is this one [1]
The issue is that the webconsole servlet is added via the legacy
HttpService API. If you wish to filter such paths using Http Whiteboard you
need to look into Felix's proprietary support for mapping Http Whiteboard
Services to legacy Http Service contexts. I do believe Felix supports this
but not sure it's documented.
But Carsten would know!
- Ray
[1]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#service.http.whiteboard.httpservice.integration
On Tue, Aug 20, 2019 at 9:37 AM Nhut Thai Le <nt...@castortech.com> wrote:
> I am using filter.pattern in the mean time but the annoying is that it does
> not allow me to exclude requests for /system/
>
> I posted a question on paxweb , waiting for answer, will update this email
> thread when i have some news
>
> Thanks you for the tips
>
> Thai
>
> On Fri, Aug 16, 2019 at 2:20 AM Georg Henzler <fe...@ghenzler.de> wrote:
>
> > Hi Thai,
> >
> > > 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?
> >
> > so osgi.http.whiteboard.filter.regex is standard [1], is this a bug in
> > the
> > whiteboard implementation paxweb then?
> >
> > you could also try to leave osgi.http.whiteboard.filter.regex out (as
> > you
> > select a specific context via osgi.http.whiteboard.context.select) or
> > use osgi.http.whiteboard.filter.pattern instead (the properties of
> > ServiceUnavailableFilter are passed one to one to
> > ServiceUnavailableFilter,
> > even if there will be a new one in the future you can just use it).
> >
> > -Georg
> >
> >
> > [1]
> >
> >
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055
> >
> > On 2019-08-15 00:23, Nhut Thai Le wrote:
> > > 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:
> > >
> >
> > >
> > > Thai
> > >
> > > On Wed, Aug 14, 2019 at 2:49 PM Nhut Thai Le <nt...@castortech.com>
> > > 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
> > >> [1]=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 <fe...@ghenzler.de>
> > >> 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
> > >> ntle@castortech.com
> > >> www.castortech.com [2]
> > >>
> > >> 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
> > > ntle@castortech.com
> > > www.castortech.com [2]
> > >
> > > 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.
> > >
> > > Links:
> > > ------
> > > [1] http://osgi.http.whiteboard.context.name
> > > [2] http://www.castortech.com
> >
>
>
> --
> 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
> ntle@castortech.com
> 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.
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Nhut Thai Le <nt...@castortech.com>.
I am using filter.pattern in the mean time but the annoying is that it does
not allow me to exclude requests for /system/
I posted a question on paxweb , waiting for answer, will update this email
thread when i have some news
Thanks you for the tips
Thai
On Fri, Aug 16, 2019 at 2:20 AM Georg Henzler <fe...@ghenzler.de> wrote:
> Hi Thai,
>
> > 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?
>
> so osgi.http.whiteboard.filter.regex is standard [1], is this a bug in
> the
> whiteboard implementation paxweb then?
>
> you could also try to leave osgi.http.whiteboard.filter.regex out (as
> you
> select a specific context via osgi.http.whiteboard.context.select) or
> use osgi.http.whiteboard.filter.pattern instead (the properties of
> ServiceUnavailableFilter are passed one to one to
> ServiceUnavailableFilter,
> even if there will be a new one in the future you can just use it).
>
> -Georg
>
>
> [1]
>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055
>
> On 2019-08-15 00:23, Nhut Thai Le wrote:
> > 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:
> >
>
> >
> > Thai
> >
> > On Wed, Aug 14, 2019 at 2:49 PM Nhut Thai Le <nt...@castortech.com>
> > 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
> >> [1]=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 <fe...@ghenzler.de>
> >> 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
> >> ntle@castortech.com
> >> www.castortech.com [2]
> >>
> >> 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
> > ntle@castortech.com
> > www.castortech.com [2]
> >
> > 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.
> >
> > Links:
> > ------
> > [1] http://osgi.http.whiteboard.context.name
> > [2] http://www.castortech.com
>
--
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
ntle@castortech.com
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.
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Georg Henzler <fe...@ghenzler.de>.
Hi Thai,
> 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?
so osgi.http.whiteboard.filter.regex is standard [1], is this a bug in
the
whiteboard implementation paxweb then?
you could also try to leave osgi.http.whiteboard.filter.regex out (as
you
select a specific context via osgi.http.whiteboard.context.select) or
use osgi.http.whiteboard.filter.pattern instead (the properties of
ServiceUnavailableFilter are passed one to one to
ServiceUnavailableFilter,
even if there will be a new one in the future you can just use it).
-Georg
[1]
https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121055
On 2019-08-15 00:23, Nhut Thai Le wrote:
> 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:
>
>
> Thai
>
> On Wed, Aug 14, 2019 at 2:49 PM Nhut Thai Le <nt...@castortech.com>
> 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
>> [1]=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 <fe...@ghenzler.de>
>> 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
>> ntle@castortech.com
>> www.castortech.com [2]
>>
>> 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
> ntle@castortech.com
> www.castortech.com [2]
>
> 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.
>
> Links:
> ------
> [1] http://osgi.http.whiteboard.context.name
> [2] http://www.castortech.com
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Nhut Thai Le <nt...@castortech.com>.
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 <nt...@castortech.com> 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 <fe...@ghenzler.de> 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
> ntle@castortech.com
> 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
ntle@castortech.com
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.
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Georg Henzler <fe...@ghenzler.de>.
>
> 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 ?
So the hc.core bundle is active (otherwise you would not have the logs).
So
is the servlet answering and the filter just not kicking in? Go to
/system/console/httpservice and check your setup. It's possible that
that
the filter is generally not active for the request you are issuing by
the
configuration of the servlet filter properties [3]
-Georg
[3]
https://github.com/apache/felix/blob/fd76982e887e82159288f1d0c1908402885d8e4c/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/filter/ServiceUnavailableFilter.java#L102-L106
> Thai
>
> On Tue, Aug 13, 2019 at 6:44 PM Georg Henzler <fe...@ghenzler.de>
> 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
> ntle@castortech.com
> 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.
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Nhut Thai Le <nt...@castortech.com>.
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 <fe...@ghenzler.de> 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
ntle@castortech.com
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.
Re: healthcheck: ServiceUnavailableFilter does not kick-in
Posted by Georg Henzler <fe...@ghenzler.de>.
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