4:01 p.m.
This is the email I mentioned on Zulip:
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
I'm working on UNDERTOW-1593/WFLY-12459, which is an RFE to add support for
tracking long-running requests (similar to what was available in EAP6. See
EAP7-1188 for more details). I have some questions that are too long, I
think, to handle in Zulip very well, so I'm going to write what will likely
be a very long email instead. :)
Currently, my impl in Undertow add a new HttpHandler to handle the...
business logic, as well as a new POJO to hold the data. That side of the
change seems very simple, but things get more complicated on the WildFly
side. Currently, I have defined a new Filter, which handles creating this
new Undertow HttpHandler. Using it looks something like this:
jboss-cli.sh -c
"/subsystem=undertow/configuration=filter/active-request-tracking=requestTracker/:add"
jboss-cli.sh -c
"/subsystem=undertow/server=default-server/host=default-host/filter-ref=requestTracker/:add()"
jboss-cli.sh -c
"/subsystem=undertow/configuration=filter/active-request-tracking=requestTracker:list-active-requests()"
Excuse me (and correct me ;) if I get some of the terminology wrong, but,
as I understand it, this is what's happening:
- When the server starts, thanks to FilterDefinitions.FILTERS, an
instance of my new Filter, ActiveRequestTrackingFilter, is created.
- With the first CLI command, using that definition, a Filter, named
'requestTracker' is created and added to the system.
- Next, a reference to that Filter is added to default-host, which will
apply the Filter to any requests on the host.
- Finally, using the operation added to the Filter (but scoped, in
theory, to the named Filter), we query Undertow, using the
HttpHandler's public API, to get the list of active requests and print that
information.
While I may have the terms right, I think I understand the process well
enough, and it works. Mostly. Here's where my real question(s) come in.
When the user executes the list-active-requests operation, I have been
unable to find a way to restrict the output (or the data gathered) to only
the hosts to which the filter has been applied. For example, let's say I
have 2 hosts: H1, and H2, and that I have created two filters, F1 and F2,
one for each host. When the HttpHandler for each filter reference is
created, there is insufficient information provided to createHttpHandler()
to determine, in that method, the host to which the FilterRef is attached.
Since the OperationStepHandler is attached to the Filter (and it seems that
there is only once instance of ActiveRequestTrackingFilter in the system),
I (currently) naively add the HttpHandler to the operation instance held by
the Filter (ActiveRequestTrackingFilter.operation), which means that
jboss-cli.sh
-c
"/subsystem=undertow/configuration=filter/active-request-tracking=F1:list-active-requests()"
will
return data captured by F2 as well.
That's a really long way of getting to the question(s), which are there:
1. Are we ok with this operation returning ALL of the active requests on
the server despite the possibility of having multiple filter-refs defined.
This is a debug operation, so maybe it's not a big deal, but it seems odd
(if not necessarily wrong) to be able to define multiple
filter/filter-refs, but they all return the same data.
2. If that's not want we want, how do fix it so that the operation gets
enough information to differentiate?
1. For example, can Handler.createHttpHandler() be modified to accept
the FilterLocation/Host?
2. Is there a better way?
As it stands now, I think my implementation meets the requirements laid out
in the Analysis Doc ("The new feature consists of adding a way for users to
retrieve active requests, ie. requests that haven’t finished and are active
on the server."). There are some oddities in the behavior (as I've tried to
describe above), so I'd love some input on either how to fix them or if we
should just accept them (for now?)
Thanks!
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP