[wildfly-dev] Re: FilterRef aware Filter Operations?

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. Yes, exactly, that's what I meant with the wildfly-proposal.

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. I haven't thought of that up to this point. I spent some time back in 2020

On Tue, Feb 15, 2022 at 4:02 PM Jason Lee <jasondlee(a)redhat.com&gt; 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 _______________________________________________ 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