hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: svn commit: r1098098
Date Thu, 05 May 2011 14:43:55 GMT
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.

Oleg



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


Mime
View raw message