[
https://issues.jboss.org/browse/WFLY-1708?page=com.atlassian.jira.plugin....
]
David Lloyd commented on WFLY-1708:
-----------------------------------
The problem is that RejectedExecutionException is expensive and difficult to handle
properly. The alternative is to queue indefinitely which is also potentially problematic.
By handling it at the handler, you essentially suspend the connection, and once enough
connections accumulate, the server connection limiting kicks in, which works as a buffer
against the server doing the Apache HTTPD thing and throwing 4xx and 5xx errors
sporadically as load increases. Instead the backlog is handled more cleanly by the server
OS and TCP/IP.
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