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.
Cheers,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
