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

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

On Mon, Feb 21, 2022 at 10:52 AM Flavia Rainone <frainone(a)redhat.com&gt; wrote: > Thanks for having a look at this, Brian! Answers inline below :-) > > On Tue, Feb 15, 2022 at 7:45 PM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; 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. >> > If this will end up with a single resource, perhaps instead of setting an attribute and then adding a runtime-only resource it would be cleaner to just create a new persistent resource and enable it via an add op. It's likely to be less typing to configure (since write-attribute/name/value/true is longer than add) and is not some special way of doing something that will need to be documented and users will need to remember. AIUI there is some interaction with the statistics-enabled attribute involved, but that needs to be handled regardless of whether an attribute or a resource is used. >> 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(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 > > > > -- > > Flavia Rainone > > Principal Software Engineer > > Red Hat <https://www.redhat.com> > > frainone(a)redhat.com > <https://www.redhat.com> > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His