Hermes Flying wrote:
Hi,
So is there an explanation for this? All I am interested is make sure that 
after a limit, clients attempted to connect are stopped based on my 
configuration on maxThreads and accept count.
But I can not figure out how this works.


(This all being explained in vernacular language to which experts may object).

Threads in Tomcat serve to process requests.  Each Thread can process one 
request.
0 Threads = 0 requests being processed.
n Threads = n requests can be processed simultaneously (kind of).

Threads "belong to" either a Connector (by default), or an Executor (if you configure several Connectors to use an Executor, then they use the common pool of Threads of the Executor, instead of their own individual pool of Threads).

Having a common pool of Threads between several Connectors is normally more efficient and allows for a smoother operation. Otherwise you could have the case that requests arriving through one Connector (e.g. HTTP) are being starved because this particular Connector has no more Threads available, while on the other hand another Connector (e.g. AJP) still has plenty of capacity.

The "acceptCount" is another matter entirely, working at a deeper level.
Before a Thread is assigned to process a request,
- the client requests a TCP connection to the server
- the server must "accept" this connection. If it doesn't within a certain time, the client will get an error (connect timeout). - when the server accepts the connection, it goes into a queue. The length of that queue corresponds to the acceptCount of the corresponding Connector.
(If the accept queue is already full, the connection request will be rejected).
As long as the server does no further action, an accepted connection stays in the queue and the client request does not proceed. If that lasts a long time, the client may timeout (usually saying that the server is not responsive). - whenever the server feels like it (for example, when it sees that it has at least one Thread free to handle a request), it will pop the first connection from the accept queue, and pass it to a Thread to be processed. Now a Thread is assigned to process this request, so one less Thread is available in the pool of Threads.
- if another client connection happens now, it goes into the accept queue.
- whenever the original Thread is done processing the request, the Thread goes back into the pool of available Threads, and could be assigned to another client request currently sitting in the accept queue.

That's roughly how it works.
If it does not do so in your case, then it must mean that you are setting your parameters in the wrong place, and Tomcat is either not seeing them at all, or ignoring them because they are not where they should be.

The default Tomcat settings are chosen by people who know what they are doing, to obtain a reasonable Tomcat behaviour over a reasonable range of conditions. If you change these settings, you can get a behaviour that is no longer reasonable or balanced. For example, if you set the accepCount to 1 and maxThreads to 1, then you can have the following :
- 1 request accepted and allocated a Thread, thus in process
- 1 additional request being queued in the accept queue, waiting for a Thread to become available And any additional client request arriving at that time will be rejected at the TCP level. That will hardly result in an error that is understandable by the clients.

Intuitively, it does not seem to make a lot of sense to set up a whole machinery like a host, a JVM and a Tomcat, just to process one single request at a time.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to