tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat 7.0.6 FIN_WAIT2 Connections and Connection Keep-Alive
Date Fri, 30 Sep 2011 21:12:42 GMT
Caldarale, Charles R wrote:
>> From: rapponcape [] 
>> Subject: Re: Tomcat 7.0.6 FIN_WAIT2 Connections and Connection Keep-Alive
>> It appears that I'll have to go back to using Apache
> Note that Tomcat is also Apache.
>> to proxy these requests to get keep-alive behavior to
>> function with these clients.
> Or fix your webapp to be spec-compliant and set the Content-Length header as it should
be doing.

That's probably the crux of it.


Suppose your client sends a request, requesting a persistent (keep-alive) connection, and

the webserver (Tomcat) is willing to grant it.

The client is reading on the connection back from Tomcat, where it is expecting the 
response being written by Tomcat (or rather, by your web application running under Tomcat).

Your web application writes a response on that connection, but does not provide a header 
with the length of the response which it is sending back.
How is the client supposed to know when the response is finished ?

Answer: It can't, so it will keep waiting forever on the connection, for more bytes to arrive.

The /only/ way for Tomcat in such a case, to let the client know that the response is 
finished, is by closing the connection.  For the client reading, this acts as an 
end-of-file, so now it knows that the response is finished.

When you think of it, that's pretty clever from Tomcat : it sees that the webapp is not 
sending a content-length, and that the client is a HTTP/1.0 client who requested a 
keep-alive connection. So it knows that the client may be waiting forever for more bytes,

and to avoid that, it closes the connection when the webapp exits, so as to let the client

know that it's finished, no more bytes are coming.

If you want to avoid this, have your web application send a content-length along with the

response.  Then Tomcat will know that since there is a content-length, the HTTP/1.0 client

should be able to tell by itself when this response is finished, and it does not need to 
close the connection.

Got it ?

By /not/ sending a content-length in the response, your webapp is giving Tomcat no choice.
It has to close the connection, and cannot leave it open (and persistent).

That is the meaning of that second phrase in the passage which you quoted from Apache httpd.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message