Thanks for having a look at this, Brian! Answers inline below :-)

On Tue, Feb 15, 2022 at 7:45 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:

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 listing all the list of possible attributes, something I found in my local copy (the resarch I was doing is unfinished, that's why it is not in the wildfly-proposal) and might be useful for you @Jason.

If possible, I think there should be a way of filtering, we just need to think more about this to better evaluate this option and the payoff it represents.

 

On Tue, Feb 15, 2022 at 4:02 PM Jason Lee <jasondlee@redhat.com> wrote:

This is the email I mentioned on Zulip: https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/FilterRef.20aware.20Filter.20Operations.3F

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@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

--

Flavia Rainone

Principal Software Engineer

Red Hat

frainone@redhat.com