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:
- 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.
- If that's not want we want, how do fix it so that the operation gets enough information to differentiate?
- For example, can Handler.createHttpHandler() be modified to accept the FilterLocation/Host?
- 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