On Thu, 2011-05-05 at 15:53 +0100, sebb wrote: > On 5 May 2011 15:43, Oleg Kalnichevski <[email protected]> wrote: > > On Thu, 2011-05-05 at 01:33 +0100, sebb wrote: > >> On 30 April 2011 12:11, <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
