Any idea why is this happening? It looks to me this is bug or a performance issue. This is killing our Windows server every 10 minutes.
Hey am,
The CLOSE_WAIT state is part of the shutting down process when you close a TCP connection. When a TCP connection that was ESTABLISHED is closed then both ends will need to ACK the closing of the connection. However, if for some reason the client is not cleanly closing the connection (e.g. it was killed) then the socket will remain in a CLOSE_WAIT state for a longer time until it times out. You can configure your OS to time out things faster if having things in CLOSE_WAIT state is a problem for you.
This is what I found from a quick Google search:
The Close_wait interval is controled by the registry setting:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Param eters
TcpTimedWaitDelay
It can range from 30-300 seconds. The default is 240.
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-u s/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/rege ntry/58770.asp
– Gato
Gato,
Thanks for your reply. We have browsers connected to OpenFire thru a flash object. The browsers always send the notification to close the connection, but openfire don’t send the ack to finally close it. So this is not a client not closing the connection issue. It looks to me openfire can’t handle that load and the connections in the CLOSE_WAIT state are getting accumulated. Do you think connection manager installed on the same computer of OpenFire could improve the situation?
PS: TcpTimedWaitDelay in the registy is used to control TIME_WAIT state, this is different than CLOSE_WAIT. Anyway we have it at 60.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/588 11.mspx?mfr=true
Hey am,
Which Windows version are you using? Which java version are you using? Are you using cygwin? Using Connection Managers will not make a difference. I’m still not convinced this is a server issue. We have several installations and load tests with much higher number of clients and never saw something like this. If you use another XMPP client, rather than your flash client, do you still see this problem?
Thanks,
– Gato
Gato,
Windows 2003 Server, Java v 6 Update 3.
We have lot of requested connections per second. Maybe the JVM can’t
handle it. I’m not sure we can make the test using another XMPP client, because
the flash object is running in the user’s browser. OpenFire can handle the load
when it has 1.7K connections, at this point the number of connections in
CLOSE_WAIT state is 0 in the whole system, after reaching 1.8K it starts growing rapidly until it kills the server.
Arm