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 15:34:19 GMT
rapponcape wrote:
> On Fri, Sep 30, 2011 at 4:51 AM, André Warnier <> wrote:
>> Rainer Jung wrote:
>>> On 29.09.2011 22:49, rapponcape wrote:
>>>>> Aha, the client is using HTTP 1.0 and not 1.1. This could be one reason
>>>>> for Tomcat closing the connection. See below.
>>>> When I reconfigure and put Apache in front of Tomcat and use a jkmount
>>>> with
>>>> AJP connector, response is normal and without error.  Appears to only
>>>> happen
>>>> when tomcat is standalone.
>>> Could be the answer is small enough, that Apache can buffer it and send
>>> without chunked encoding. Don't know.
>>>>>> You see: no Content-Length header. I
>>>> I do see Content-Length in the POST header
>>> You cut out the relevant part. I was talkingabout the Tomcat answer, you
>>> saw it in the client request. That's now the same ;)
>>> Rainer
>> rapponcape,
>> to clarify maybe the discussion and answers which you have received so far :
>> 1) Your clients, in their requests, indicate a protocol level HTTP/1.0.
>> If you read RFC2616 (HTTP 1.1), you will see that for HTTP 1.0, the
>> persistent ("keep-alive") kind of connection is not very well defined.
>> Keep-alive connections are only well-defined and supported in HTTP/1.1.
>> Consequently, a HTTP/1.1-capable server (like Apache httpd and Tomcat), upon
>> receiving a request specifying HTTP/1.0, cannot assume that the client
>> really knows how to handle this properly, and /can/ decide to not honor the
>> desire for keep-alive connections, and close the connection after every
>> response.
>> In this case, it appears that Apache httpd may follow one behaviour, and
>> Tomcat the other.
>> Other webservers may choose to do either one or the other.
>> (Both behaviours are allowed by the RFC).
>> The point is : if your client wants to increase its chances to get a
>> keep-alive connection, then it should use HTTP/1.1, not HTTP/1.0.
>> 2) When your client connects to Apache httpd, and httpd serves as a proxy to
>> Tomcat, there are two independent connections :
>> client <-- (1) --> Apache httpd + mod_jk <-- (2) ---> Tomcat
>> It is allowed for (Apache httpd + mod_jk) to make a proxy connection (2) to
>> Tomcat using a HTTP 1.1 protocol level, allowing for persistent connections,
>> even if on the other side (1) the connection is HTTP/1.0 and not persistent.
>> (In fact, here this is pretty much irrelevant, since the connection (2) is
>> made under the AJP protocol, not HTTP.  And mod_jk will always try to use
>> persistent connections to Tomcat, for efficiency).
>> So it is very possible that your client sees a different behaviour when it
>> talk to Apache httpd, compared to when it talks to Tomcat directly.
>> But that is because your client indicates that it wants a protocol level
>> HTTP/1.0.
>> So, in summary :
>> - Apache httpd and Tomcat are right, because they follow the RFC
>> - your client is wrong, inasmuch as it has an unfounded expectation, using
>> HTTP/1.0, to actually get a persistent connection when it asks for it.
>> It should be added that, even under HTTP/1.1, there is no guarantee for the
>> client that when it asks for a persistent connection, it will actually get
>> one.  The HTTP 1.1 server can still decide to close the connection after the
>> response, for a variety of reasons.
>> But let's say that it would have a much better chance.
>> And let's leave the question of chunked responses for the next step.
> Very helpful detail.
> It would be nice to see Tomcat react similarly to how Apache reacts to
> HTTP/1.0 messages that specify Keep-Alive and Content Length.  From
> Apache docs...
> "For HTTP/1.0 clients, Keep-Alive connections will only be used if
> they are specifically requested by a client. In addition, a Keep-Alive
> connection with an HTTP/1.0 client can only be used when the length of
> the content is known in advance."
Sorry to insist, but do you really understand the implications of the 2d phrase above ?
Is your Tomcat application setting a content-length /in its response/ ?

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

View raw message