You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2006/05/17 17:43:56 UTC
DO NOT REPLY [Bug 39600] New: - A lot of connection in TIME_WAIT state on Tomcat clients
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
Summary: A lot of connection in TIME_WAIT state on Tomcat clients
Product: Tomcat 5
Version: 5.5.12
Platform: Other
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: lionel.agulhon@club-internet.fr
Each client connection performed on our Tomcat server is in TIME_WAIT state on
client (even if the client is the Tomcat server itself). We have studied the
network capture and we found an abnormal behaviour :
When the client send the FIN segment, Tomcat server reply with a FIN segment
instead of ACK. So the client send ACK and enter in TIME_WAIT state and it's a
ugly behaviour when the client server support a hudge traffic (during a stress
campaign we have reached 21000 TIME_WAIT connection !). In the TCP RFC, Closing
a TCP session is always a 4 way handshake (->FIN,ACK ->,FIN ->,->Ack).
you can easly reproduce :
perform on the tomcat server : telnet localhost [tomcat_port]
GET /toto \n\n
perform : netstat -an |grep [tomcat_port]
you should see a connection in TIME_WAIT State.
Thanks for help, Rgds.
--
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
DO NOT REPLY [Bug 39600] - A lot of connection in TIME_WAIT state on Tomcat clients
Posted by 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
yoavs@computer.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From yoavs@computer.org 2006-12-25 05:08 -------
While we can add the shutdownOutput call right before socket.close, I largely
agree with Darryl's analysis so I hesitate to muck with this low-level
functionality that's been seriously tested over several years now, at least not
without further tests / information from the original poster.
OP: if your problem persists with 5.5.20, could you please try adding the
shutdownOutput call to Http11BaseProtocol as Darryl suggests, building a custom
Tomcat, and re-running your tests? I'd be very curious as to the results. If
you do this, please reopen this Bugzilla issue and append your further
information. Thanks.
--
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
DO NOT REPLY [Bug 39600] - A lot of connection in TIME_WAIT state on Tomcat clients
Posted by 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