On 09/05/2020 14:08, Vikas Kumar wrote:
> I did not know about the images being dropped.
> Here are the steps I depicted in the image:
> Step 0: Request accepted by OS
> Step 1: Request sent to Tomcat. Tomcat accepts the request if it's internal
> queue is not full, else rejects the request
> Step 2: Tomcat adds the request to the queue if all worker threads are
> busy, else sends the request to one of the free worker threads
> Step 3: Request is picked by the worker thread for processing

The above sequence isn't quite right.

Step 0 is the accept queue. See acceptCount in the docs. Note that not
every OS honours this setting and may use a smaller or larger value. It
the accept queue is full, the connection gets dropped.

Step 1 is the Acceptor thread. This runs in a fairly tight loop. If the
current connection count > maxConnections, the loop pauses. The Acceptor
thread takes the next connection from the accept queue, accepts it
(creates the connection) and then creates a task for the executor to
process that connection. It then loops. If the connection isn't accepted
in time, it will time out. The queue for the executor is essentially
unlimited - although in practice it should never exceed maxConnections

Step 2 Is the executor. If there are tasks in the queue and spare worker
threads available, the task (== connection) is allocated a worker thread
for processing.

Step 3 is that the executor/worker thread processes the connection. When
the request is completed, the connection is either kept open (e.g. HTTP
keep alive) or closed.

> I would like to add a hook between step(1) and step (2). As I mentioned
> earlier, I want to dynamically control the Tomcat internal queue size based
> on some application logic. Is there a way to do that?

Do you want to control the acceptCount, maxConnections or something else?

What problem are you trying to solve?

The overhead of the accept process and the allocation of requests to
workers is fairly light weight. I wonder if the simplest solution would
be to allow every request through to the application and then decide
whether to process it or reject it. You could provide an HTTP error
response at that point that might be more informative for your users.


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

Reply via email to