[WFLY-12459] Initial analysis for active request tracking feature. #275
Conversation
There was a problem hiding this comment.
I've put some comments there as I think some details shall be added into the analysis.
To be honest, I am not quite sure I like approach to use filter-ref in specific hosts. Maybe I don't understand the thoughts behind this completely. Would not be easier to simply add a boolean attribute in the /subsystem=undertow/server=default-server/host=default-host or even some reference in /subsystem=undertow/server=default-server/host=default-host/settings=<something> to enable/disable such future per particular hosts?
| * mailto:{email}[{author}] | ||
|
|
||
| === QE Contacts | ||
|
|
| // Discuss with QE during the Kickoff state to decide this | ||
| [ ] Engineering | ||
|
|
||
| [ ] QE |
There was a problem hiding this comment.
I suppose this one may be tested by QE.
| As an example, look at the cli script below: | ||
|
|
||
| .... | ||
| subsystem=undertow/set-attribute(name="active-request-statistics-enabled", "true") |
There was a problem hiding this comment.
Is this command correct? Isn't it supposed to be rather /subsystem=undertow:write-attribute(name="active-request-statistics-enabled", "true").
There was a problem hiding this comment.
Correct; there is no 'set-attribute' operation.
| .... | ||
| See the example bellow: | ||
| ---- | ||
| subsystem=undertow/active-request-tracker=requestTracker:list-active-requests |
There was a problem hiding this comment.
Where does the name requestTracker comes from? In previous example, there was name enabled used:
subsystem=undertow/active-request-tracker=enabled
| <host name="default-host" alias="localhost"> | ||
| <location name="/" handler="welcome-content"/> | ||
| <http-invoker security-realm="ApplicationRealm"/> | ||
| </host> |
There was a problem hiding this comment.
I think that there is filter-ref element for requestTracker missing in host element.
| </servlet-container> | ||
| <handlers> | ||
| <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> | ||
| </handlers> |
There was a problem hiding this comment.
Do I understand this correctly, that there is no 'requestTrackerinstance in thefilters` element of Undertows configuration, right?
| list-active-requests | ||
| list-active-requests(format="same as an Undertow access log formatting") | ||
| list-active-requests-with-id | ||
| list-active-requests-full |
There was a problem hiding this comment.
How is this operation different from simple list-active-requests?
|
|
||
| The operation below will show just the requested attributes from the request: | ||
| ---- | ||
| subsystem=undertow/active-request-tracker=requestTracker:list-active-requests(attributes="bytes-sent,bytes-received") |
There was a problem hiding this comment.
In previous operations description, there is format attribute specified:
list-active-requests(format="same as an Undertow access log formatting")
does this mean that this is another possible attribute? are these attributes optional/mutual exclusive?
There was a problem hiding this comment.
Also, is there specified a complete list of attributes that will be collected for each active request somewhere?
| Notice that, in order for the track to start tracking actual requests, it must be referenced as a filter inside the server as in: | ||
| ---- | ||
| /subsystem=undertow/server=default-server/host=default-host/filter-ref=requestTracker:add | ||
| ---- |
There was a problem hiding this comment.
If I understand this, then this filter reference will be kind of a reference to a virtual filter, right? How is this reflected in the configuration XML? What if user defines its own filter named requestTracker? Shall we deny this name?
There was a problem hiding this comment.
AIUI the intent in the above bit is to describe the automatic internal behavior as being the same as what would happen if a filter-ref was actually in the config. Not that there would actually be such a thing in the config, and thus no "add" operation to set it up.
| === Other Interested Projects | ||
|
|
||
| == Requirements | ||
| The new feature consists of adding a way for users to retrieve active requests, ie. |
There was a problem hiding this comment.
Can't be this use case covered by standard subsystem /metrics we already have in Wildfly? There are several undertow related values already? Or is this somehow different?
@jmesnil wdyt?
| As a result, we will have a new resource in the Undertow Subsystem with the name: | ||
|
|
||
| ..... | ||
| subsystem=undertow/active-request-tracker=enabled |
There was a problem hiding this comment.
Isn't this /subsystem=undertow/active-request-tracker=request-tracker?
Also AIUI this is a runtime-only resource (e.g. it does not appear in the xml config shown below). That should be stated explicitly.
AIUI this is a fixed-name resource (aka a 'singleton'). Some name like /subsystem=undertow/service=active-request-tracker is better. The general pattern of address elements is "general type"="specific name". It's better to make up a general type than to not follow the pattern. The only thing to be careful about is not using some 'general type' that later you will want to use for a resource type where the user can provide the specific name.
There was a problem hiding this comment.
hi @bstansberry I will fix this.
fl4via
force-pushed
the
WFLY-12459_active_request_tracking
branch
from
25f98fc to
0e3fbbb
Compare
|
I have just updated the analysis document to the latest format. |
Solves wildfly#663 Signed-off-by: Flavia Rainone <frainone@redhat.com>
fl4via
force-pushed
the
WFLY-12459_active_request_tracking
branch
from
0e3fbbb to
ff7dff2
Compare
Analysis for Active request tracking #663
Jira: https://issues.redhat.com/browse/WFLY-12459