TIME_WAIT means "client enters this state after active close".
It's normal to have a socket in this state for a period of time. This time
is specified by the rfc 793 as twice the MSL (Maximum Segment Lifetime).
Some systems implement different values but the specification is 2 mn.

I read this comment from internet... I think it could help you!

Setting the TCP TIME_WAIT time
When you expect to serve many TCP/IP connections, it is important to check
the time your Server OS waits before releasing a logically closed TCP/IP
socket. If this time is too long, those "died" sockets can consume all OS
TCP/IP resources, and all new connections will be rejected on the OS level,
so the CommuniGate Pro Server will not be able to warn you. 
This problem can be seen even on the sites that have just few hundred
accounts. This indicates that some of the clients have configured their
mailers to check the server too often. If client mailers connect to the
server every minute, and the OS TIME_WAIT time is set to 2 minutes, the
number of "died" sockets will grow, and eventually, they will consume all OS
TCP/IP resources. 

It is recommended to set the TIME_WAIT time to 20-30 seconds. 

The TIME_WAIT problem is a very common one for Windows NT systems. Unlike
most Unix systems, Windows NT does not have a generic setting for the
TIME_WAIT interval modification. To modify this setting, you should create
an entry in the Windows NT Registry (the information below is taken from the
http://www.microsoft.com site:

Run Registry Editor (RegEdit.exe). 
Go to the following key in the registry: 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters 
Choose Add Value from the Edit menu and create the following entry:
Value Name: 
TcpTimedWaitDelay 
Data Type: 
REG_DWORD 
Value: 
30-300 (decimal) - time in seconds 
Default: 0xF0 (240 decimal) not in registry by default 
Quit the Registry Editor 
Restart the computer for the registry change to take effect. 
Description: This parameter determines the length of time that a connection
will stay in the TIME_WAIT state when being closed. While a connection is in
the TIME_WAIT state, the socket pair cannot be reused. This is also known as
the "2MSL" state, as by RFC the value should be twice the maximum segment
lifetime on the network. See RFC793 for further details. 


-----Message d'origine-----
De : V D [mailto:[EMAIL PROTECTED] 
Envoyé : mercredi 15 décembre 2004 05:17
À : [EMAIL PROTECTED]
Objet : Server refuse connection with many TIME_WAIT


I have an Axis service that runs under Tomcat 5.5.4.  I use gSoap client 
to connect to the server.  After about 3960 requests from the clients, 
the Tomcat stops accepting connection.  I have to wait for serveral 
minutes for it to accept connections again.

This is under MS Windows XP system.  Using the command line:

netstat -a<enter>

I have about 5000 TIMEWAIT:

TCP    vd:5000                localhost:http         TIME_WAIT

Looking through TcpMonitor, both the client and server send in close 
message:

CLIENT MESSAGE:

POST /axis/services/TestService HTTP/1.1
Host: 127.0.0.1:82
User-Agent: gSOAP/2.7
Content-Type: text/xml; charset=utf-8
Content-Length: 552
Connection: close
SOAPAction: ""

....

SERVER MESSAGE:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Wed, 15 Dec 2004 04:04:52 GMT
Connection: close

What's going on?  Is there any flag I can set in Tomcat to close these 
TIMEWAIT connections?

Looking at the clients's memory foot print, the memory does not go up at 
all after all these connections.
The strange thing is this:  using Java's client to repeatedly request 
the server for many thousand times, and I don't have any problem with 
the server.  Using the command line "netstat -a", and I still see many 
TIMEWAIT.

Could this have something to do with gSoap, not Tomcat?

Thanks,

V D






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to