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