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 <[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
[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 <[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 [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
[email protected]
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
