[WFCORE-7222] Ability to set IO Subsystem worker queue size

Add analysis document

undertow/WFCORE-7022-Ability_to_set_IO_Subsystem_worker_queue_size.adoc

@@ -0,0 +1,128 @@
+---
+categories:
+- undertow
+stability-level: default
+issue: https://github.com/wildfly/wildfly-proposals/issues/618
+feature-team:
+ developer: jasondlee
+ sme:
+  - TBD
+ outside-perspective:
+  - TBD
+promotes:
+promoted-by:
+---
+= Ability to set IO Subsystem worker queue size
+:author:            Jason Lee
+:email:             [email protected]
+: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
+
+Currently, the only way to set the worker queue size is via a https://access.redhat.com/solutions/2433971[JMX bean]: `org.xnio:type=Xnio,provider="nio",worker="your-workername"` (`your-workername` defaults to `default` which is defined in `standalone-*.xml`). This can be done via a https://access.redhat.com/solutions/4937251[startup EJB], a https://access.redhat.com/solutions/2604501[remote JMX Client], or even `jconsole`, for example. Users have long requested the ability to set this value via the standard management configuration module. This RFE will add this management property and related code changes to implement this request.
+
+=== 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.>__
+
+== Issue Metadata
+
+=== Related Issues
+
+* https://issues.redhat.com/browse/WFCORE-7022[WFCORE-7022]
+* https://issues.redhat.com/browse/EAPSUP-456[EAPSUP-456]
+* https://issues.redhat.com/browse/EAP7-1698[EAP7-1698]
+
+=== Affected Projects or Components
+
+- https://github.com/xnio/xnio
+- https://github.com/undertow-io/undertow
+- https://github.com/wildfly/wildfly-core/
+- https://github.com/wildfly/wildfly
+
+=== 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 management model will be updated to add a "max worker queue" attribute, whose default value will be null, allowing the underlying `TaskPool` implementations to configure themselves as they are now.
+* To avoid cascading changes into multiple projects, the value will be set via the aforementioned MBean.
+
+=== Changed requirements
+
+Not relevant
+
+=== Non-Requirements
+
+None
+
+=== Future Work
+
+None
+
+== Backwards Compatibility
+
+The max worker queue value will default to the current value, so there should be no backwards compatibility issues.
+
+=== Default Configuration
+
+No
+
+=== Importing Existing Configuration
+
+These changes will not require any changes to existing configuration.
+
+=== Deployments
+
+This feature is opt-in, and will not affect existing deployments in any way.
+
+=== Interoperability
+
+There are no interoperability issues with this change.
+
+== Security Considerations
+
+None
+
+[[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.
+*** 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.>__