tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD
Date Thu, 11 May 2017 11:37:37 GMT
I believe that the explanation given below by Guido is incorrect and misleading, as it 
seems to confuse CLOSE_WAIT with TIME_WAIT.
See : TCP/IP State Transition Diagram (RFC793)

CLOSE-WAIT represents waiting for a connection termination request from the local user.

TIME-WAIT represents waiting for enough time to pass to be sure the remote TCP received 
the acknowledgment of its connection termination request.

Thus, CLOSE_WAIT is a /normal/ state of a TCP/IP connection.  There is no timeout for it 
that can be set by any TCP/IP parameter. Basically it means : the remote cient has closed

this connection, and the local OS is waiting for the local application to also close its 
side of the connection. And the local OS is going to wait - for an undefinite amount of 
time - until that happens (or until the process which has this connection still opens, 
exits). And in this case, the process which has this connection open, is the JVM which 
runs Tomcat (which by definition never exits, until you terminate Tomcat).

Many connections in the CLOSE_WAIT state mean, in most cases, that the application running

under Tomcat, is not closing its sockets properly.
(This can happen in some "devious" ways, not easy to immediately diagnose).

Try the following : when you notice a high number of connections in CLOSE_WAIT state, 
force the JVM which runs Tomcat, to do a Major Garbage Collection.
(I do this using jmxsh, but there are several other way to do this)
And check after this, how many CLOSE_WAIT connections are still there.

On 11.05.2017 11:03, Adhavan Mathiyalagan wrote:
> Thanks Guido !
> On Thu, May 11, 2017 at 12:02 PM, Jäkel, Guido <> wrote:
>> Dear Adhavan,
>> I think this is quiet normal, because the browser clients "in front" will
>> reuse connections (using keep-alive at TCP level) but an in-between load
>> balancer may be not work or configured in this way and will use a new
>> connection for each request to the backend.
>> Then, you'll see a lot of sockets in the TCP/IP closedown workflow between
>> the load balancer and the backend server. Pleases refer to TCP/IP that the
>> port even for a "well closed connection" will be hold some time to handle
>> late (duplicate) packets. Think about a duplicated, delayed RST packet -
>> this should not close the next connection to this port.
>> Because this situation is very unlikely or even impossible on a local area
>> network, you may adjust the TCP stack setting of your server to use much
>> lower protection times (in the magnitude of seconds) and also adjust
>> others. And at Linux, you may also expand the range of ports used for
>> connections.
>> BTW: If you have a dedicated stateful packet inspecting firewall between
>> your LB and the server, you also have to take a look on this.
>> Said that, one more cent about the protocol between the LB and the Tomcat:
>> I don’t know about HTTP, but if you use AJP (with mod_jk) you may configure
>> it to keep and reuse connections to the Tomcat backend(s).
>> Guido
>>> -----Original Message-----
>>> From: Adhavan Mathiyalagan []
>>> Sent: Wednesday, May 10, 2017 6:32 PM
>>> To: Tomcat Users List
>>> Subject: CLOSE_WAIT between Application (Tomcat) and Apache HTTPD
>>> Team,
>>> Tomcat version : 8.0.18
>>> Apache HTTPD version : 2.2
>>> There are lot of CLOSE_WAIT connections being created at the
>>> Application(tomcat)  ,when the traffic is routed through the Apache HTTPD
>>> load balancer to the Application running over tomcat container. This leads
>>> to slowness of the port where the Application is running and eventually
>> the
>>> application is not accessible through that particular PORT.
>>> In case of the traffic directly reaching the Application PORT without
>>> (Load balancer) there is no CLOSE_WAIT connections created and
>> application
>>> can handle the load seamlessly.
>>> Thanks in advance for the support.
>>> Regards,
>>> Adhavan.M

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

View raw message