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 14:53:32 GMT
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().

> 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