On 5 May 2011 16:07, sebb <[email protected]> wrote: > 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.
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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
