tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat connections
Date Fri, 29 Apr 2011 20:46:51 GMT
Monty wig wrote:
> Gurus - I am working on a situation where Apache spits "Proxy Errors" while
> trying to get a page form Tomcat.
> We are running Apache 2.2.3 and tomcat 5.5 on the same box and using
> mod_proxy to redirect traffic to tomcat on port 8080. Tomcat has
> maxThreads=150 but when we look at the total # of connection on tomcat using
> "netstat" we get around 80 established connection, 140 connection in
> TIME_WAIT. So my question is does 150 maxThreads means total # of
> connections (ESTABLISHED + WAIT_TIME) or only ESTABLISHED connections...
> Any help will be appreciated...

TIME_WAIT (or TIMED_WAIT) is a normal state for the "client" in a TCP connection (the 
client being the side which has started the connection in the first place).
It happens when the client decides to close the connection and sends a packet to that 
effect to the server. It then goes in the TIME_WAIT state, while waiting for the server to

close its end of the connection (and say so to the client).

Normally, this state lasts only a very short time. If it persists for a long time, then it

would indicate a network problem, which for a connection that is between an Apache process

and a Tomcat process on the same box, is quite unlikely and bizarre.
So make sure that these TIME_WAIT sockets are really between Apache+mod_proxy and Tomcat 
(use "netstat -pan --tcp" if you are on a Linux system e.g., it will show the process-id 
of the "owner" of the connection).

The "maxThreads" attribute of a Tomcat Connector, is - as the name indicates - the maximum

number of Tomcat threads that this Connector will start, to process incoming requests.
So, suppose that
- Tomcat is not currently doing anything
- your Connector has maxThreads="150"
- you are sending 200 requests simultaneously to Tomcat through that Connector
- the Connector will start up to 150 threads, enabling it to start processing 150 of the 
200 requests
- the 50 remaining requests may be queued up in the TCP wait queue for this socket, 
waiting for a thread to become available to process them, one after the other
- as soon as one Tomcat thread finishes processing its current request, it will be 
available to process one of the requests in the socket queue.
But this depends on how long it takes to process the shortest request that was already 
attributed to a thread.  If it takes very long for a request to be accepted and start 
being processed, then the client side (here Apache+mod_proxy) may give up, and return an 
error to the client application.

That is what you may see as a "proxy error".

You may well have set the maxThreads=150, but Tomcat may be unable to start as many 
threads, for example because of some resource limitation (memory ?). So requests start 
piling up in the socket accept queue for the Connector, without being processed.  And when

that queue in turn reaches its maximum capacity (see the "backlog" or "acceptCount" 
attribute), that socket (8080) may start rejecting new connections right away.
(But I believe that this would trigger an error of the type "The server is not responding

and may be busy..".)

Apart from the "netstat" utility, two other tools may help you determine what is going on
- the Apache "mod_status" module (which returns a page showing what the Apache children 
processes are doing)
- the Tomcat Manager application (which shows a server status page showing what the 
threads are doing)
Also mod_proxy itself may give you more details in the Apache error log.

Normally, ESTABLISHED connections between Apache and Tomcat should more or less correspond

to the number of requests being actively processed, which should also correspond to one 
active Apache child process (or thread) having sent a request to Tomcat, and to a thread 
in Tomcat processing that request.
But this is not a strict one-to-one relationship, because there may be connections which 
are still alive due to the KeepAlive factor, while real activity has stopped on the channel.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message