Caldarale, Charles R wrote:
From: rapponcape [mailto:rapponc...@gmail.com]
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.
rapponcape,
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
