tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: CLOSE_WAIT
Date Wed, 02 Feb 2011 16:37:28 GMT
Peter Crowther wrote:
> On 2 February 2011 10:24, Bw57899 <bw57899@gmail.com> wrote:
> 
>> Install an application in apache tomcat (6.0.29) in dev env on Solaris 10
>> with no issue.
>>
>> But after move to production, there are always about 50 ~ 100 CLOSE_WAIT on
>> port 1521. The application need connect an Oracle database which is on
>> another server.
>>
>> So what can I do to check the problem?
>>
>> CLOSE_WAIT is normal behaviour - after a TCP socket is closed, it's
> tombstoned for a period so that the TCP stack knows what to do with incoming
> datagrams that might be late.
> 
Peter,
I do not think that this is true, and I believe that you are confusing this with the 
TIME_WAIT state.
See for example this :
http://support.microsoft.com/kb/137984

CLOSE_WAIT:
A socket application has been terminated, but Netstat reports the socket in a CLOSE_WAIT 
state. This could indicate that the client properly closed the connection (FIN has been 
sent), but the server still has its socket open. This could be the result of one instance

(among all threads or processes) of the socket not being closed.


I had/have a case like that with a third-party Tomcat application.
It goes typically like this :

The webapp creates an object C which among other things makes a TCP connection to another

server.
The webapp then uses this object's methods to send/receive data from the other server.
At the end of this exchange, the webapp sends a command to the external server, to tell it

"I'm done".  The external server then closes its end of the connection.
Now the webapp, by means of closing the connection, sets the object C = null.
For the webapp, this means that the connection object C is now effectively "closed".
But in fact, the object C still exists somewhere on the heap, and it still holds on to its

underlying (OS-level) socket, which has never been closed from the Tomcat server side.
The underlying TCP connection is in the CLOSE_WAIT state, because the socket has never 
been closed on the Tomcat server side, and it remains "dangling".
It only disappears when the Tomcat JVM does a GC, and the Object C is really discarded.
That really closes the underlying TCP socket, and then the state progresses LAST_ACK and 
finally CLOSED and gone.

An easy way to verify if this is the case of the OP, is to force Tomcat to do a GC, and 
see if these CLOSE_WAIT connections then disappear.

If it is the case, then I would advise the OP to check his webapp, to see if it does not 
do the same kind of thing as described above.

One problem that I have seen happen with this, is that as the number of CLOSE_WAIT sockets

increases (to a few hundred), the whole server becomes unable to handle further TCP 
connections of any kind, being in the practice paralysed.
I suppose that there must exist some inherent limit as to the maximum number of sockets 
which a system (or a process) can have active at any one time.





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


Mime
View raw message