[
https://issues.jboss.org/browse/WFLY-1708?page=com.atlassian.jira.plugin....
]
David Lloyd commented on WFLY-1708:
-----------------------------------
The CAS is only contended if the given handler already would be invoked. In this case a
CAS is generally going to be just about the smallest tick on the CPU consumption of what
is, after all, otherwise going to be a blocking handler. And I think you can potentially
win back that cost just by having substantially fewer threads in the system, in many
cases.
Per-deployment web thread pools
-------------------------------
Key: WFLY-1708
URL:
https://issues.jboss.org/browse/WFLY-1708
Project: WildFly
Issue Type: Feature Request
Components: Web (Undertow)
Reporter: James Livingston
Assignee: Stuart Douglas
It would be nice if you could limit the number of worker threads being used by an
application, and one way of achieving that would be to add a per-deployment thread pool
for handing web requests.
This can be done currently by configuring one <connector> per application and
giving each one it's own thread pool.
Undertow supports (from cursory inspection) DeploymentInfo.setExecutor/setAsyncExecutor()
which configured the Executor to use for requests. The subsystem could read a thread pool
configuration from jboss-web.xml and pass the resulting executor into those two methods to
make setting this up easier and not require a load balancer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira