4:44 p.m.
Reading this I better understand why Flavia's issue analysis at
https://github.com/wildfly/wildfly-proposals/pull/275/files was talking in
terms of a single configuration attribute that results in the addition of a
single runtime-only management resource.
These two commands make sense as a way to describe to developers the
*internal* mechanisms of what will happen:
/subsystem=undertow/configuration=filter/active-request-tracking=requestTracker/:add
/subsystem=undertow/server=default-server/host=default-host/filter-ref=requestTracker/:add
But those and
/subsystem=undertow/configuration=filter/active-request-tracking=requestTracker:list-active-requests()
are not a very good management API to expose to users, IMHO.
The fact that we are using a filter behind the scenes to capture data is an
implementation detail. It seems odd to me that I as a user would go to a
"filter" resource to learn about active requests. It would be even more odd
to go to a 'filter-ref' resource (as a way to scope the data to a
particular host.)
A question is whether there is any way to capture the total information
such that reading a subset of it (e.g. for a host) is possible. And then
can that subset be logically associated with one of the undertow subsystem
management resources (e.g. default-server and default-host as opposed to
www.foo.com or 192.168.199.199). If not, then a single top level resource
makes sense. If yes, then resources scoped to a host makes sense, if the
benefit is worth the effort.
On Tue, Feb 15, 2022 at 4:02 PM Jason Lee <jasondlee(a)redhat.com> wrote:
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
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His