hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r1098098
Date Thu, 05 May 2011 15:07:52 GMT
On 5 May 2011 16:04, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Thu, 2011-05-05 at 15:53 +0100, sebb wrote:
>> On 5 May 2011 15:43, Oleg Kalnichevski <olegk@apache.org> wrote:
>> > On Thu, 2011-05-05 at 01:33 +0100, sebb wrote:
>> >> On 30 April 2011 12:11,  <olegk@apache.org> wrote:
>> >
>> > ...
>> >
>> >> +    /**
>> >> +     * Defines the timeout in milliseconds used when retrieving an instance
of
>> >> +     * {@link org.apache.http.conn.ManagedClientConnection} from the
>> >> +     * {@link org.apache.http.conn.ClientConnectionManager}.
>> >> +     * <p>
>> >> +     * This parameter expects a value of type {@link Long}.
>> >>
>> >> Why is this Long?
>> >>
>> >> The related parameter CoreConnectionPNames.CONNECTION_TIMEOUT is an Integer.
>> >>
>> >
>> > This goes back to the jolly ol' days of HttpClient 2.x and the very
>> > first versions of MultiThreadedHttpConnectionManager, when features
>> > mattered most and developers were much less concerned with the clarity
>> > and consistency of the API.
>> >
>> >
>> >> Not sure I understand why the ConnMgr Timeout should default to the
>> >> Connection Timeout.
>> >
>> > I personally do not see a lot of convincing reasons to differentiate
>> > these two cases. Ultimately both serve to ensure that I/O threads do not
>> > block indefinitely waiting for a connection. 4.1 version was released
>> > with the former deprecated in favor of the latter. If we want to
>> > re-introduce the connection manager timeout as a separate parameter, at
>> > the very least we should make an effort to preserve behavioral
>> > compatibility with 4.1.
>> >
>> >
>> >> [Also one is long, the other int.]
>> >>
>> >
>> > Historical. See above.
>> >
>> >> If the ConnMgr timeout is not set, I would expect it to default to 0
>> >> (i.e. infinite)
>> >>
>> >
>> > Again, this is done for the sake of compatibility with 4.1. If you think
>> > this makes things even more confusing, I am fine with changing the
>> > behavior of the pooling connection manager. In this case, though, we
>> > will end up breaking applications that rely on the connect timeout to
>> > ensure that connection manager operations do not block indefinitely. At
>> > the very least this will need to be documented and explained.
>>
>> OK, I see.
>>
>> In that case I'll document the current behaviour of
>> getConnectionManagerTimeout().
>>
>
> What happened to the initial idea of moving this logic to the
> DefaultRequestDirector?

It got lost in the ether - I'll do that (with Javadoc) instead.

> cheers
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> 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