https://bz.apache.org/bugzilla/show_bug.cgi?id=59650
Ravi Sanwal <rsan...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |REOPENED
--- Comment #2 from Ravi Sanwal <rsan...@gmail.com> ---
OK,
My email reply didn't make it here.
The snippet you mentioned here checks if the supplied executor is instance of
ExecutorService is.
Well, an executor configured in server.xml is not. Which means that the
threadGroup is never created (with the provided thread pool) and eventually it
ends up using the default case. Which is an unbounded thread pool.
In addition to this undesired behavior, for NIO2 connector, these threads (the
ones to process async IO) are reused as-is to process new requests. If we have
configured an executor in server.xml, our expectation is that requests are
processed (or in case of async, are started to be processed) by the executor
threads.
A small example would reveal this problem.
Configure a server with an executor of size 1 (max). Write an async servlet to
serve a filesystem resource. Hit it from a client with lots of requests coming
in parallel and see what threads on tomcat jvm are doing.
Another one to try is, have two servlets one async and one non-async. Send a
request from a browser to the async servlet first and then to the other one.
You'll see that the executor thread is not used for the second one, instead
since the first request was "kept-alive" the second one lands on the same
connection and so, uses the thread that was previously used to write output on
that connection for the async request. Which is not an executor thread, but a
thread from the async channel processor group.
The side-effect of this is that there is no way to throttle threads. They just
keep growing, even if most of the just sit idle.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
