Return-Path: 
 <dev-return-23836-apmail-hc-dev-archive=hc.apache.org@hc.apache.org>
X-Original-To: apmail-hc-dev-archive@www.apache.org
Delivered-To: apmail-hc-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 07D1D2764
	for <apmail-hc-dev-archive@www.apache.org>;
 Thu,  5 May 2011 14:54:00 +0000 (UTC)
Received: (qmail 64909 invoked by uid 500); 5 May 2011 14:53:59 -0000
Delivered-To: apmail-hc-dev-archive@hc.apache.org
Received: (qmail 64868 invoked by uid 500); 5 May 2011 14:53:59 -0000
Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hc.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hc.apache.org>
List-Post: <mailto:dev@hc.apache.org>
List-Id: <dev.hc.apache.org>
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Delivered-To: mailing list dev@hc.apache.org
Received: (qmail 64857 invoked by uid 99); 5 May 2011 14:53:59 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 May 2011 14:53:59 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 209.85.220.179 as permitted sender)
Received: from [209.85.220.179] (HELO mail-vx0-f179.google.com)
 (209.85.220.179)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 May 2011 14:53:53 +0000
Received: by vxi40 with SMTP id 40so2366631vxi.10
        for <dev@hc.apache.org>; Thu, 05 May 2011 07:53:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:content-type:content-transfer-encoding;
        bh=tTUlp+iUVCubn0mR45T7HwpDaUOROc7FiT1CJhHBHZc=;
        b=E3yRLCtrRnQH/gDsAyRaXyPf94Hbd1VKzG2M4vMlO1QivAZwbWAJGa9ZAgEMfpM4lm
         6IBLlntChZaJdluErdQiY3iWDvlWUVcdptfr90iKXrn4nFSfkw0DiQvqi/9oocuAsnJw
         HT+3H0ctOVbBe+CAQchjU08ic5ErDLSf/KrGM=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=kuCqWONg9P7TlOyJsFlDg3T+nYD+vSHVcsn6vDXdrR+B9y/HVfNthxnGVet2CTPIVL
         2EVppIaNSlZB2W/XzVEH0PGID8oJyPOrLnNlBSWKu/22fls2+TX3ElJkhlj9d5bO9/Iw
         x4EEjCZAKmaSZY3pfVxk5aKv2LPuQA1eVqKc4=
MIME-Version: 1.0
Received: by 10.52.175.133 with SMTP id ca5mr1636613vdc.82.1304607212656; Thu,
 05 May 2011 07:53:32 -0700 (PDT)
Received: by 10.220.176.67 with HTTP; Thu, 5 May 2011 07:53:32 -0700 (PDT)
In-Reply-To: <1304606635.5487.74.camel@ubuntu>
References: <20110430111151.A77942388A39@eris.apache.org>
	<BANLkTinLC-WcjSXA4bGgCA5LvM_e8KQDgA@mail.gmail.com>
	<1304606635.5487.74.camel@ubuntu>
Date: Thu, 5 May 2011 15:53:32 +0100
Message-ID: <BANLkTiknycECYfCjax46S2-eBcLKdFdwgw@mail.gmail.com>
Subject: Re: svn commit: r1098098
From: sebb <sebbaz@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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, =A0<olegk@apache.org> wrote:
>
> ...
>
>> + =A0 =A0/**
>> + =A0 =A0 * Defines the timeout in milliseconds used when retrieving an =
instance of
>> + =A0 =A0 * {@link org.apache.http.conn.ManagedClientConnection} from th=
e
>> + =A0 =A0 * {@link org.apache.http.conn.ClientConnectionManager}.
>> + =A0 =A0 * <p>
>> + =A0 =A0 * This parameter expects a value of type {@link Long}.
>>
>> Why is this Long?
>>
>> The related parameter CoreConnectionPNames.CONNECTION_TIMEOUT is an Inte=
ger.
>>
>
> 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().

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

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