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 15:04:34 GMT
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?

cheers

Oleg



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


Mime
View raw message