From 02ca15549f82a90e22d5fd0b7aa28fdc5193fa25 Mon Sep 17 00:00:00 2001 From: Jason Lee Date: Thu, 5 Jun 2025 10:34:26 -0500 Subject: [PATCH] WEJBHTTP-154 - Add proposal analysis document --- ...ort_TCP_NODELAY_in_wildfly-config_xml.adoc | 252 ++++++++++++++++++ 1 file changed, 252 insertions(+) create mode 100644 undertow/WEJBHTTP-154_Support_TCP_NODELAY_in_wildfly-config_xml.adoc diff --git a/undertow/WEJBHTTP-154_Support_TCP_NODELAY_in_wildfly-config_xml.adoc b/undertow/WEJBHTTP-154_Support_TCP_NODELAY_in_wildfly-config_xml.adoc new file mode 100644 index 00000000..f2878a65 --- /dev/null +++ b/undertow/WEJBHTTP-154_Support_TCP_NODELAY_in_wildfly-config_xml.adoc @@ -0,0 +1,252 @@ +--- +# 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 +- ejb +# Specify the stability level of the feature. +# Values can be one of: experimental, preview, community, or default +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/732 +# Provide the GitHub ids of the feature team members, 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: jasondlee + sme: + - + outside-perspective: + - +# If this issue tracks the promotion of a previously completed feature to a higher stability level, provide the URL of +# the original https://github.com/wildfly/wildfly-proposals/issues issue that was used to track the implementation of +# that feature. +promotes: +# During initial development of a feature, this field should be left blank. If after the feature is completed and its +# stability level is promoted via a later issue, the developer promoting the issue should return to this document ("this" +# being the original analysis document for the feature). The field should be updated to point to the +# https://github.com/wildfly/wildfly-proposals/issues issue that promotes it. +# For example, +# | Implementation Issue (A) | Promotion Issue (B) +# promotes: | | https://github.com/.../A +# promoted-by: | https://github.com/.../B | +promoted-by: +--- + += Support TCP_NODELAY in wildfly-config.xml +:author: Jason Lee +:email: jasondlee@redhat.com +:toc: left +:icons: font +:idprefix: +:idseparator: - + + +//// +The entire document should be one to two pages long. We will write each analysis document as if it is a conversation +with a future developer. This requires a good writing style, with full sentences organized into paragraphs. Bullets are +acceptable only for visual style, not as an excuse for writing sentence fragments. +//// + +== Overview + +The socket option `TCP_NODELAY` is not configurable, either programmatically or via XML. This leads, in some cases, to unacceptable performance +characteristics. To remedy this, `WildFlyHttpContext` and its related XML schema need to be updated to allow this option to be configured by the +developer. + +=== User Stories + +//// +Provide one or more brief user stories that illustrate the intended users of the feature and the goal they will seek +to achieve by using the feature. +//// + +As an application developer, I would like greater flexibilty in configuring the socket used by the HTTP EJB client. + +== Issue Metadata + +* https://issues.redhat.com/browse/WEJBHTTP-154 + +=== Related Issues + +//// +List the issues related to this feature +//// + +=== Affected Projects or Components + +//// +List the projects or components that are affected by the feature. List them using their Git repositories. +//// + +=== Other Interested Projects + +* Undertow +* EJB + +=== Relevant Installation Types + +//// +List the installation types that are relevant for the features and remove any that are not relevant. +//// + +* Traditional standalone server (unzipped or provisioned by Galleon) +* Managed domain +* OpenShift Source-to-Image (S2I) +* Bootable jar + +== Requirements + +//// +Describe the requirements that must be fulfilled by this feature. + +For analyses of a promotion of an existing feature to 'preview' or 'community' stability, only list new requirements; +existing requirements from the feature being promoted are assumed to continue unless otherwise noted in the 'Changed +requirements' section. Other analyses, including those for promotion to the 'default' stability level, must list all +requirements. +//// + +* The `wildfly-http-client` schema version should be modified to add support for `TCP_NODELAY` +* `WildFlyHttpContext` should be modified to add support for `tcpNoDelay`. + +=== Changed requirements +//// +Only relevant for analyses of a promotion of an existing feature to 'preview' or 'community stability. Other analyses +should remove this section. + +For any existing requirements from the feature being promoted that are being changed or removed, describe the change. +//// +N/A + +=== Non-Requirements +//// +Use this section to explicitly discuss things that readers might think are required but which are not required. +//// +N/A + +=== Future Work +//// +Use this section to discuss requirements that are not addressed by this proposal but which may be addressed in later proposals. +//// + +N/A + +== Backwards Compatibility +//// +Does this enhancement affect backwards compatibility with previously released versions of WildFly? Can the identified +incompatibility be avoided? +//// + +This change will include a new version of the XML schema, but the old version will still be fully supported. There should +not, then, be any bacwards compatibility issues. + +=== Default Configuration +//// +Does the proposed work change the default value of any current configuration attributes? Does it change the +configuration generated by any current Galleon layers? +//// + +There will be no default configuration changes. Any added elements/properties will default to their current, unconfigured values. + +=== Importing Existing Configuration +//// +Does the proposed work affect the ability to run WildFly running an existing configuration? Is there anything else +about the proposed work that may require changes to the WildFly server migration tool? +//// + +Existing configurations will continue to work unchanged. + +=== Deployments +//// +Does this feature change the behavior of deployments in incompatible ways? If yes, please detail what is the deployment +issue observed when no change is done, and what is the change needed to solve the deployment issue. +//// + +Unless deployments opt in to use the new schema version, they will be unaffected by this change. + +=== Interoperability +//// +Is this feature impacting interoperability? +//// + +There are no interop issues foreseen. + +== Implementation Plan +//// +This section is optional. If you have a complex feature which cannot be delivered all in one go, suggest the strategy. +//// + +N/A + +== Admin Clients +//// +Identify the level of compatibility this feature will have with the existing admin clients (JBoss CLI and the Admin +Console / HAL). Identify any follow-up work that will be required in the clients and link issues created to track this work. +//// + +N/A + +== Security Considerations +//// +What impact on security does this feature have? +//// + +There no security considerations foreseen. + +[[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. +//// +... + +== 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. +//// + +Updates have been made to the `wildfly-http-client` schema and `WWildFlyHttpContext` to allow for greater flexibilty in configuring +the socket used by the EJB client.