hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin" <sber...@gmail.com>
Subject Re: Keep-Alive timeout & persistent connections
Date Thu, 26 Jun 2008 04:06:06 GMT
FYI, the fix is in there now (along with a bunch of new tests), and a
new 'closeExpiredConnections' method that can be used the same way
closeIdleConnections works if you want to bulk-close all expired
connections at any given moment.

Sam

On Wed, Jun 25, 2008 at 5:52 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Wed, 2008-06-25 at 17:42 -0400, Sam Berlin wrote:
>> Done @ https://issues.apache.org/jira/browse/HTTPCLIENT-781 .  I can
>> take a look at this in the coming days -- do you think an
>> implementation that just closes the prior connection & makes a new one
>> on a subsequent request is OK, or does HttpClient need to close the
>> connection immediately once the timeout elapses?  (I don't think the
>> latter is possible without an additional thread.)
>>
>
> I think the former is good enough, but a possibility to introduce a more
> sophisticated eviction policy would be an advantage. This however does
> not seem to require changes in the public API so it could be done after
> BETA1. What we need to do before the API freeze is to ensure there is a
> way to set a timeout value on individual managed connections.
>
> Oleg
>
>
>> Sam
>>
>> On Wed, Jun 25, 2008 at 5:33 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > On Wed, 2008-06-25 at 17:14 -0400, Sam Berlin wrote:
>> >> Hi Folks,
>> >>
>> >> We just stumbled across an issue with persistent connections where the
>> >> server is sending a Connection: Keep-Alive header, but also a
>> >> Keep-Alive header with a timeout=## (and a max=##).  HttpClient's
>> >> connection management sees that the connection can be kept alive, so
>> >> pools it for potential reuse, but doesn't respect the timeout (or max)
>> >> values.  The problem is that the connection remains opens from the
>> >> eyes of HttpClient.  A subsequent request sends correctly (with no
>> >> IOX's, oddly enough), but reading causes HttpClient to read a -1 and
>> >> throw a NoHttpResponseException.  This is against a run-of-the-mill
>> >> Apache httpd server.
>> >>
>> >> This is normally supposed to be handled by a HttpRequestRetryHandler,
>> >> to retry to the connection, but I'm wondering if it shouldn't even get
>> >> there in the first place.  Should HttpClient respect the Keep-Alive
>> >> header's timeout (and max, or other) token and use a new connection in
>> >> the first place?
>> >>
>> >
>> > Hi Sam
>> >
>> > We certainly need to fix that. Could you please open a JIRA for this
>> > issue?
>> >
>> > Oleg
>> >
>> >> Sam
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> >> For additional commands, e-mail: dev-help@hc.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> > For additional commands, e-mail: dev-help@hc.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

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


Mime
View raw message