Skip to content

Commit 02ca155

Browse files
jasondleejasondlee
committed
WEJBHTTP-154 - Add proposal analysis document
1 parent 508e667 commit 02ca155

File tree

1 file changed

+252
-0
lines changed

1 file changed

+252
-0
lines changed

‎undertow/WEJBHTTP-154_Support_TCP_NODELAY_in_wildfly-config_xml.adoc‎

Lines changed: 252 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,252 @@
1+
---
2+
# Add any category for this proposal as a YAML list, e.g.
3+
# - core
4+
# - management
5+
# If missing, add it to _data/wildfly-categories and use its id
6+
categories:
7+
- undertow
8+
- ejb
9+
# Specify the stability level of the feature.
10+
# Values can be one of: experimental, preview, community, or default
11+
stability-level: default
12+
# Specify the Feature Development tracker issue for the feature.
13+
# This must be an issue tracked in https://github.com/orgs/wildfly/projects/7/views/1.
14+
# To create a Feature Development tracker issue, go to https://github.com/wildfly/wildfly-proposals/issues/new/choose
15+
# and select 'Feature Development'
16+
issue: https://github.com/wildfly/wildfly-proposals/issues/732
17+
# Provide the GitHub ids of the feature team members, organized by role.
18+
# Provide a single id for the 'assignee' role. Use a YAML list for the 'sme' and
19+
# 'outside-perspective' roles, even if there is only one person in a role.
20+
feature-team:
21+
developer: jasondlee
22+
sme:
23+
-
24+
outside-perspective:
25+
-
26+
# If this issue tracks the promotion of a previously completed feature to a higher stability level, provide the URL of
27+
# the original https://github.com/wildfly/wildfly-proposals/issues issue that was used to track the implementation of
28+
# that feature.
29+
promotes:
30+
# During initial development of a feature, this field should be left blank. If after the feature is completed and its
31+
# stability level is promoted via a later issue, the developer promoting the issue should return to this document ("this"
32+
# being the original analysis document for the feature). The field should be updated to point to the
33+
# https://github.com/wildfly/wildfly-proposals/issues issue that promotes it.
34+
# For example,
35+
# | Implementation Issue (A) | Promotion Issue (B)
36+
# promotes: | | https://github.com/.../A
37+
# promoted-by: | https://github.com/.../B |
38+
promoted-by:
39+
---
40+
41+
= Support TCP_NODELAY in wildfly-config.xml
42+
:author: Jason Lee
43+
:email: jasondlee@redhat.com
44+
:toc: left
45+
:icons: font
46+
:idprefix:
47+
:idseparator: -
48+
49+
50+
////
51+
The entire document should be one to two pages long. We will write each analysis document as if it is a conversation
52+
with a future developer. This requires a good writing style, with full sentences organized into paragraphs. Bullets are
53+
acceptable only for visual style, not as an excuse for writing sentence fragments.
54+
////
55+
56+
== Overview
57+
58+
The socket option `TCP_NODELAY` is not configurable, either programmatically or via XML. This leads, in some cases, to unacceptable performance
59+
characteristics. To remedy this, `WildFlyHttpContext` and its related XML schema need to be updated to allow this option to be configured by the
60+
developer.
61+
62+
=== User Stories
63+
64+
////
65+
Provide one or more brief user stories that illustrate the intended users of the feature and the goal they will seek
66+
to achieve by using the feature.
67+
////
68+
69+
As an application developer, I would like greater flexibilty in configuring the socket used by the HTTP EJB client.
70+
71+
== Issue Metadata
72+
73+
* https://issues.redhat.com/browse/WEJBHTTP-154
74+
75+
=== Related Issues
76+
77+
////
78+
List the issues related to this feature
79+
////
80+
81+
=== Affected Projects or Components
82+
83+
////
84+
List the projects or components that are affected by the feature. List them using their Git repositories.
85+
////
86+
87+
=== Other Interested Projects
88+
89+
* Undertow
90+
* EJB
91+
92+
=== Relevant Installation Types
93+
94+
////
95+
List the installation types that are relevant for the features and remove any that are not relevant.
96+
////
97+
98+
* Traditional standalone server (unzipped or provisioned by Galleon)
99+
* Managed domain
100+
* OpenShift Source-to-Image (S2I)
101+
* Bootable jar
102+
103+
== Requirements
104+
105+
////
106+
Describe the requirements that must be fulfilled by this feature.
107+
108+
For analyses of a promotion of an existing feature to 'preview' or 'community' stability, only list new requirements;
109+
existing requirements from the feature being promoted are assumed to continue unless otherwise noted in the 'Changed
110+
requirements' section. Other analyses, including those for promotion to the 'default' stability level, must list all
111+
requirements.
112+
////
113+
114+
* The `wildfly-http-client` schema version should be modified to add support for `TCP_NODELAY`
115+
* `WildFlyHttpContext` should be modified to add support for `tcpNoDelay`.
116+
117+
=== Changed requirements
118+
////
119+
Only relevant for analyses of a promotion of an existing feature to 'preview' or 'community stability. Other analyses
120+
should remove this section.
121+
122+
For any existing requirements from the feature being promoted that are being changed or removed, describe the change.
123+
////
124+
N/A
125+
126+
=== Non-Requirements
127+
////
128+
Use this section to explicitly discuss things that readers might think are required but which are not required.
129+
////
130+
N/A
131+
132+
=== Future Work
133+
////
134+
Use this section to discuss requirements that are not addressed by this proposal but which may be addressed in later proposals.
135+
////
136+
137+
N/A
138+
139+
== Backwards Compatibility
140+
////
141+
Does this enhancement affect backwards compatibility with previously released versions of WildFly? Can the identified
142+
incompatibility be avoided?
143+
////
144+
145+
This change will include a new version of the XML schema, but the old version will still be fully supported. There should
146+
not, then, be any bacwards compatibility issues.
147+
148+
=== Default Configuration
149+
////
150+
Does the proposed work change the default value of any current configuration attributes? Does it change the
151+
configuration generated by any current Galleon layers?
152+
////
153+
154+
There will be no default configuration changes. Any added elements/properties will default to their current, unconfigured values.
155+
156+
=== Importing Existing Configuration
157+
////
158+
Does the proposed work affect the ability to run WildFly running an existing configuration? Is there anything else
159+
about the proposed work that may require changes to the WildFly server migration tool?
160+
////
161+
162+
Existing configurations will continue to work unchanged.
163+
164+
=== Deployments
165+
////
166+
Does this feature change the behavior of deployments in incompatible ways? If yes, please detail what is the deployment
167+
issue observed when no change is done, and what is the change needed to solve the deployment issue.
168+
////
169+
170+
Unless deployments opt in to use the new schema version, they will be unaffected by this change.
171+
172+
=== Interoperability
173+
////
174+
Is this feature impacting interoperability?
175+
////
176+
177+
There are no interop issues foreseen.
178+
179+
== Implementation Plan
180+
////
181+
This section is optional. If you have a complex feature which cannot be delivered all in one go, suggest the strategy.
182+
////
183+
184+
N/A
185+
186+
== Admin Clients
187+
////
188+
Identify the level of compatibility this feature will have with the existing admin clients (JBoss CLI and the Admin
189+
Console / HAL). Identify any follow-up work that will be required in the clients and link issues created to track this work.
190+
////
191+
192+
N/A
193+
194+
== Security Considerations
195+
////
196+
What impact on security does this feature have?
197+
////
198+
199+
There no security considerations foreseen.
200+
201+
[[test_plan]]
202+
== Test Plan
203+
204+
////
205+
Depending on the selected stability level, the appropriate section below should be completed, including a brief
206+
description of how testing is to be performed in accordance with the selected stability level. The non-relevant sections
207+
may be removed as needed.
208+
209+
Depending on the stability level, the test plan required may vary. See below.
210+
////
211+
212+
** Experimental - No test plan is required. Basic unit / integration tests should be added during development.
213+
214+
** Preview - a brief high-level description of the testing approach should be added here, including types of tests added
215+
(unit, integration, smoke, component, subsystem, etc.) Note that not all test types are required for a particular feature,
216+
so include a description of what is being tested and the approach chosen to perform the testing.
217+
218+
** Community - this level should include everything in the 'Preview' stability level, plus the following additional testing as relevant:
219+
*** Manual tests: briefly describe checks to be performed during one-time exploratory testing. The purpose of this testing
220+
is to check corner cases and other cases that are not worth implementing as automated tests. Typical checks are: bad
221+
configurations are easy to reveal, attribute descriptions and error messages are clear, names are descriptive and consistent
222+
with similar resources, default values are reasonable. If there is an existing quickstart affected by the feature, manual
223+
checks include following the quickstart's guide and verifying functionality.
224+
*** Miscellaneous checks: Manual checks for significant changes in server performance, memory and disk footprint should
225+
be described here. These checks are not always relevant, but consideration of these impacts, and others, are strongly
226+
encouraged and should be described here. Fully qualified test case names should be provided along with a brief description
227+
of what the test is doing.
228+
*** Integration tests - At the 'Community' stability level, complete integration tests should be provided.
229+
*** Compatibility tests - If backwards compatibility is relevant to the feature, then describe how the testing is performed.
230+
** Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise.
231+
232+
== Community Documentation
233+
////
234+
Describe how this feature will be documented or illustrated. Generally a feature should have documentation as part of
235+
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
236+
bring additional content (such as quickstarts, guides, etc.) Indicate which of these will happen.
237+
////
238+
...
239+
240+
== Release Note Content
241+
242+
////
243+
Draft verbiage for up to a few sentences on the feature for inclusion in the Release Note blog article for the release
244+
that first includes this feature.
245+
246+
Example article: https://www.wildfly.org/news/2024/01/25/WildFly31-Released/
247+
248+
This content will be edited, so there is no need to make it perfect or discuss what release it appears in.
249+
////
250+
251+
Updates have been made to the `wildfly-http-client` schema and `WWildFlyHttpContext` to allow for greater flexibilty in configuring
252+
the socket used by the EJB client.

0 commit comments

Comments
 (0)