On 5 May 2011 16:04, Oleg Kalnichevski <[email protected]> wrote: > 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?
It got lost in the ether - I'll do that (with Javadoc) instead. > cheers > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
