On 02/23/2010 10:09 PM, James Roper wrote:
Hi,
I'm trying to understand how the Tomcat 6.0 NIO connector handles the
various limit attributes in the configuration, particularly in regards
to comet requests. I've had a look at the source code, and I think I
understand, but I'd like to confirm my understanding, and also ask
some further questions.
The acceptCount works just like it does on the other processors, it
gets passed to the ServerSocket as the backlog parameter. This limit
will be reached if the acceptor thread(s) aren't able to accept new
requests quickly enough. This is where behaviour differs from the
default HTTP connector, all the acceptor threads do is add the channel
to a poller which uses the NIO selectors to wait on activity, and then
return quickly. As far as I can see, the number of active selectors
can be unlimited, is that right? Would there be any advantages in
limiting this? What would happen if such a limit was reached? On the
default HTTP connector though, when new requests arrive, the handler
will block until it can get a free worker thread, so the acceptCount
limit could easily be reached. In order to reach the acceptCount
limit in the NIO connector, the server would have to be under a
massive amount of load, such that the accept thread never gets
scheduled to accept new connections. This would be a difficult limit
to reach, so the acceptCount is possibly not a very useful parameter
for the NIO connector.
The maxThreads is the maximum number of worker threads, this is pretty
straight forward, these threads do the actual work of the requests,
eventually calling some servlet service() or comet processor event()
method.
There is another pool for comet requests, this is the connections map
in the NIO connector. This is unlimited, and it's used to store all
comet requests that are not currently being processed by a worker
thread. Would there be any advantages to limiting this? What would
happen if such a limit was reached?
The poller threads just select on all the active channels, and hand
work off to the worker threads. The number of threads allowed in this
pool enforce no limits on concurrent requests.
So, if my understanding of all this is correct, I can fire
thousands/millions of requests at the example code in
http://tomcat.apache.org/tomcat-6.0-doc/aio.html, and there is nothing
in Tomcat that will prevent these from all being accepted, even if
doing so may cause the server to become unresponsive as it tries to
send a message to one million clients, or may cause out of memory
errors. Would it be beneficial for Tomcat to have an inbuilt
mechanism to fail gracefully should such a situation occur? I know
that part of the advantage of NIO is that it handles DoS situations
that are caused by making a small number of requests that read/write
very slowly much better than the thread per request model, so such
limits may be unlimited by default, but some applications may be able
to benefit from setting a limit in Tomcat.
yes, having a maxConnections limit is beneficial.
Cheers,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
