-
Notifications
You must be signed in to change notification settings - Fork 80
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[WFLY-12459] Analysis for active request tracking feature.
Solves #663 Signed-off-by: Flavia Rainone <frainone@redhat.com>
- Loading branch information
Showing
1 changed file
with
237 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,237 @@ | ||
| --- | ||
| # Add any category for this proposal as a yaml list, e.g. | ||
| # - core | ||
| # - management | ||
| # if missing, add it to _data/wildfly-categories and use its id | ||
| categories: undertow | ||
|
|
||
| stability-level: default | ||
| # Specify the Feature Development tracker issue for the feature. | ||
| # This must be an issue tracked in https://github.com/orgs/wildfly/projects/7/views/1. | ||
| # To create a Feature Development tracker issue, go to https://github.com/wildfly/wildfly-proposals/issues/new/choose | ||
| # and select 'Feature Development' | ||
| issue: https://github.com/wildfly/wildfly-proposals/issues/663 | ||
|
|
||
| # Provide the github ids of the members of the feature team, organized by role. | ||
| # Provide a single id for the 'assignee' role. Use a yaml list for the 'sme' and | ||
| # 'outside-perspective' roles, even if there is only one person in a role. | ||
| feature-team: | ||
| developer: fl4via | ||
| sme: | ||
| - TBD | ||
| outside-perspective: | ||
| - TBD | ||
| promotes: | ||
| promoted-by: | ||
| --- | ||
| = WFLY-12473 Active Request Tracking | ||
| :author: Flavia Rainone | ||
| :email: frainone@redhat.com | ||
| :toc: left | ||
| :icons: font | ||
| :idprefix: | ||
| :idseparator: - | ||
|
|
||
| == Overview | ||
| Currently, WildFly does not provide a way of tracking information pertaining to active requests. While it is true that the connector statistics provides the amount of active requests, that is all you can view related to those. | ||
| We propose to provide a way of fully tracking the active requests in the web server. An operation will be added to CLI to retrieve that information, and a JMX component will be added as well. | ||
|
|
||
| === User Stories | ||
|
|
||
| - as a system administrator, I would like to be able to view information pertaining active requests. This allows me not only to evaluate if there is any problematic request, but also to assess the current system demand. If there are too many active requests, or if the payload size of those requests is too big, it can be easily spotted. Other information, such as error count, remote address, can also be useful to identify issues with the server. | ||
|
|
||
| == Issue Metadata | ||
|
|
||
| === Related Issues | ||
|
|
||
| * https://issues.redhat.com/browse/WFLY-12459 | ||
| * https://issues.redhat.com/browse/EAP7-1188 | ||
| * https://issues.redhat.com/browse/UNDERTOW-1593 | ||
|
|
||
| === Affected Projects or Components | ||
|
|
||
| Undertow, WildFly Undertow Subsystem | ||
|
|
||
| === Other Interested Projects | ||
|
|
||
| === Relevant Installation Types | ||
|
|
||
| * Traditional standalone server (unzipped or provisioned by Galleon) | ||
| * Managed domain | ||
| * OpenShift Source-to-Image (S2I) | ||
| * Bootable jar | ||
|
|
||
| == Requirements | ||
|
|
||
|
|
||
| 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 was a similar feature in EAP6 and the plan is to be able to provide something similar | ||
| in EAP7 with Undertow. | ||
|
|
||
| Since there is an added impact for tracking active requests, the feature has to be | ||
| enabled to be used. To enable the feature, we are adding an attribute to Undertow | ||
| subsystem, called `"active-request-statistics-enabled"`. | ||
|
|
||
| That attribute can only be set to `true` if `"statistics-enabled"` is `true`. | ||
|
|
||
| Once that feature is enabled, there is an added resource to undertow server | ||
| called "active-request-tracker=enabled" | ||
| As an example, look at the cli script below: | ||
|
|
||
| .... | ||
| subsystem=undertow/set-attribute(name="active-request-statistics-enabled", "true") | ||
| .... | ||
|
|
||
| As a result, we will have a new resource in the Undertow Subsystem with the name: | ||
|
|
||
| ..... | ||
| subsystem=undertow/active-request-tracker=enabled | ||
| ..... | ||
|
|
||
| This tracker can later be referenced for reading the active requests with the operations: | ||
| .... | ||
| list-active-requests | ||
| list-active-requests(format="same as an Undertow access log formatting") | ||
| list-active-requests-with-id | ||
| list-active-requests-full | ||
| active-request-info(id="id") | ||
| .... | ||
| See the example bellow: | ||
| ---- | ||
| subsystem=undertow/active-request-tracker=requestTracker: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") | ||
| ---- | ||
|
|
||
| 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 | ||
| ---- | ||
|
|
||
| The coresponding XML subsystem configuration is as follows: | ||
|
|
||
| .standalone.xml | ||
| [source,xml] | ||
| ---- | ||
| <subsystem xmlns="urn:jboss:domain:undertow:11.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other" statistics-enabled="true" activer-request-statistics-enabled="true"> | ||
| <buffer-cache name="default"/> | ||
| <server name="default-server"> | ||
| <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/> | ||
| <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> | ||
| <host name="default-host" alias="localhost"> | ||
| <location name="/" handler="welcome-content"/> | ||
| <http-invoker security-realm="ApplicationRealm"/> | ||
| </host> | ||
| </server> | ||
| <servlet-container name="default"> | ||
| <jsp-config/> | ||
| <websockets/> | ||
| </servlet-container> | ||
| <handlers> | ||
| <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> | ||
| </handlers> | ||
| </subsystem> | ||
| ---- | ||
|
|
||
| The attributes that will be printed by the tracker are: | ||
|
|
||
| * `id` | ||
| * `bytes-sent` %B" "%b" "%{BYTES_SENT}" | ||
| * `bytes-received` | ||
| * `processing-time` | ||
| * `authentication-type` %{AUTHENTICATION_TYPE}" | ||
| * cookie %{c ----} | ||
| * date-time "%t" %{DATE_TIME}"; "%{time,"; | ||
| * host-and-port "%{HOST_AND_PORT}"; | ||
| * ident-username %l | ||
| * local-ip "%{LOCAL_IP}" "%A"; | ||
| * local-port "%p" "%{LOCAL_PORT}" | ||
| * local-server-name "%v" %{LOCAL_SERVER_NAME}" | ||
| * %{p path parameter | ||
| * predicate context ${... } ou $... | ||
| * query parameter %{q,...} | ||
| * query string "%q" "%{QUERY_STRING}" "%{BARE_QUERY_STRING}" | ||
| * relative-path "%R" %{RELATIVE_PATH}" | ||
| * remote-host "%h" REMOTE_HOST = "%{REMOTE_HOST}" | ||
| * remote-ip "%a" %{REMOTE_IP}" | ||
| * remote-obfuscated-ip "%o" %{REMOTE_OBFUSCATED_IP}" | ||
| * remote-user "%u" REMOTE_USER = "%{REMOTE_USER}" | ||
| * request-cookie "%{req-cookie," | ||
| * request-header "%{i,...} | ||
| * request-line "%r" REQUEST_LINE = "%{REQUEST_LINE}" | ||
| * method or request-method "%m" "%{METHOD}" | ||
| * path or request-path "%{REQUEST_PATH}" | ||
|
|
||
| === Changed requirements | ||
|
|
||
| === Non-Requirements | ||
|
|
||
| === Future Work | ||
|
|
||
| In the old versions of the server, there was also a servlet that would print the information. We might consider adding that in the future. | ||
|
|
||
| == Backwards Compatibility | ||
|
|
||
| This enhancement does not affect backwards compatibility. | ||
|
|
||
| === Default Configuration | ||
|
|
||
| No default configuration will be changed in the server. | ||
|
|
||
| === Importing Existing Configuration | ||
|
|
||
| No impact when importing existing configuration. | ||
|
|
||
| === Deployments | ||
|
|
||
| This feature does not affect deployments. | ||
|
|
||
| === Interoperability | ||
|
|
||
| This feature does not impact interoperability. | ||
|
|
||
| == Admin Clients | ||
|
|
||
| We will not have impact in the admin clients. The feature will be available when statistics are enabled. | ||
|
|
||
| == Security Considerations | ||
|
|
||
| There is no impact on security. | ||
|
|
||
| [[test_plan]] | ||
| == Test Plan | ||
|
|
||
| __<Depending on the selected stability level, the appropriate section below should be completed, including a brief description of how testing is to be performed in accordance with the selected stability level. The non-relevant sections may be removed as needed.>__ | ||
| //// | ||
| Depending on the stability level, the test plan required may vary. see below: | ||
| //// | ||
|
|
||
| ** Experimental - No test plan is required. Basic unit / integration tests should be added during development. | ||
|
|
||
| ** Preview - a brief high-level description of the testing approach should be added here, including types of tests added (unit, integration, smoke, component, subsystem, etc.) Note that not all test types are required for a particular feature, so include a description of what is being tested and the approach chosen to perform the testing. | ||
|
|
||
| ** Community - this level should include everything in the 'Preview' stability level, plus the following additional testing as relevant: | ||
| *** Manual tests: briefly describe checks to be performed during one-time exploratory testing. The purpose of this testing is to check corner cases and other cases that are not worth implementing as automated tests. Typical checks are: bad configurations are easy to reveal, attribute descriptions and error messages are clear, names are descriptive and consistent with similar resources, default values are reasonable. | ||
| If there is an existing quickstart affected by the feature, manual checks include following the quickstart's guide and verifying functionality. | ||
| *** Miscellaneous checks: Manual checks for significant changes in server performance, memory and disk footprint should be described here. These checks are not always relevant, but consideration of these impacts, and others, are strongly encouraged and should be described here. Fully qualified test case names should be provided along with a brief description of what the test is doing. | ||
| *** Integration tests - at the 'Community' stability level, complete integration tests should be provided. | ||
| *** Compatibility tests - if backwards compatibility is relevant to the feature, then describe how the testing is performed. | ||
|
|
||
| ** Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise. | ||
|
|
||
| == Community Documentation | ||
|
|
||
| __<Describe how this feature will be documented or illustrated. Generally a feature should have documentation as part of the PR to wildfly main, or as a follow-up PR if the feature is in wildfly-core. In some cases though the feature will bring additional content (such as quickstarts, guides, etc.). Indicate which of these will happen>__ | ||
| +** Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise. | ||
|
|
||
| == Release Note Content | ||
|
|
||
| __<Draft verbiage for up to a few sentences on the feature for inclusion in the Release Note blog article for the release that first includes this feature.__ | ||
| __Example article: https://www.wildfly.org/news/2024/01/25/WildFly31-Released/.__ | ||
| __This content will be edited, so there is no need to make it perfect or discuss what release it appears in.>__ |