DO NOT REPLY [Bug 39600] - A lot of connection in TIME_WAIT state on Tomcat clients

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39600>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39600





------- Additional Comments From darryl@darrylmiles.org  2006-05-19 04:35 -------
TIME_WAIT state isn't such a big problem on Linux anymore (in like last 4
years+).  The only memory overhead in the kernel is specialized timewait
structure not a full network socket.  cat /proc/slabinfo  | grep tw_sock

Some would argue that if the shutdownInput()/shutdownOutput() cycles of the
network socket can be controlled to leave the client holding the TIME_WAIT that
is better than leaving the server with it.  As under normal load you spread this
facet of TCP networking our across many hosts (when you give it the client).

A TCP closing handshake does not have to be a 4 way event, this is just the
ideal theoretial the RFC states (imagine both ends closing at the same time and
the initial FINs crossing in flight).  In anycase this is a kernel level issue
not a TC issue, as it does not matter how badly any application configures a
socket, it is still the kernels job to produce correct TCP on the wire no matter
what.


May I ask what configuration you are running with TC HTTP Server socket ?

* Java Sockets (the default on 8080)
* APJ1x Connector (the default on 8007)
* ApachePortableRuntime (genrally requires a bit of setting up to get going)


Now time to pin the tail on the donkey:

If you are using Java Sockets directly to clients, from SVN Revision: 407700 at
./tomcat/connectors/trunk/http11/src/java/org/apache/coyote/http11/Http11BaseProtocol.java:707

< try { if (socket != null) socket.close (); }

> try { if (socket != null) { socket.shutdownOutput();
>                                        socket.close (); } }

Might alter that behaviour.


It is unclear to me where you think there is a problem.  Your test requests I
use localhost (127.0.0.1) to test, but this makes me both the client and the
server, so if any TIME_WAIT is going to happen my host is definatly going to get it.

The only cause for concern here would be if you are saying that when you compare
Apache-Httpd, Squid and Tomcat under high load characteristics you find that
Apache-Httpd and Squid have few/no TIME_WAIT sockets at either the client or
server ends of the HTTP connection but with Tomcat you are getting many (at the
client end you state) then that would be something to investigate.  As they
should perform the same and I would guess it is a socket shutdown issue at the
root of it.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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