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 18:18:54 GMT
On 5 May 2011 16:07, sebb <sebbaz@gmail.com> wrote:
> 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.

On second thoughts, I think it would be better to just document the
behaviour of the getConnectionManagerTimeout() method.
That way, any other RequestDirector implementations can make use of
the same default logic.

The situation for 4.1.x is a bit different, as there is no
getConnectionManagerTimeout() method.

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