Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
MIME-Version: 1.0
In-Reply-To: <1452614812.6521.12.camel@apache.org>
References: <2356A8A3-B4FA-4DD4-A190-662DAB0DCDC6@gmail.com>
	<1452086834.15625.3.camel@apache.org>
	<1B94B260-077D-42FF-BF54-2445E9F44F93@gmail.com>
	<1452614812.6521.12.camel@apache.org>
Date: Tue, 12 Jan 2016 08:25:18 -0800
Message-ID: 
 <CACZkXPyY0n7O7erg-P4h5GYznaSH=mP2_CrXpWPqHx0TWdRmDw@mail.gmail.com>
Subject: Re: Default timeouts
From: Gary Gregory <garydgregory@gmail.com>
To: HttpComponents Project <dev@hc.apache.org>
Cc: Gaspard Petit <gaspardpetit@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a8bfacfaa900529257fe6

--047d7b3a8bfacfaa900529257fe6
Content-Type: text/plain; charset=UTF-8

On Jan 12, 2016 8:06 AM, "Oleg Kalnichevski" <olegk@apache.org> wrote:
>
> On Sun, 2016-01-10 at 22:51 -0500, Gaspard Petit wrote:
> > Hi Oleg,
> >
> > Thank you for taking the time to respond my comment.
> >
> > I agree with you that timeouts are not one-size-fits-all.  However, I
cannot think of any real-world application that would require to use an
infinite timeout.  When the SSL handshake has been waiting on the socket
for over 2 days, there is no doubt that the application is in failure state
and should either retry or abandon.
> >
> > The cases where infinite timeouts are useful, in my opinion, are
strictly when debugging the code, to let you grab a coffee while stepping
through the code.
> >
> > Anything between 20s and 2 minutes would be reasonable.  I would
personally go for something like this:
> >
> > Default SSL Handshake socket timeout : 30s
> > Socket (Request) timeout : 30s
> > Connection timeout : 60s
> >
> > Most likely, current HttpClient users are already defining their
timeouts, so only few users should be negatively impacted by such a change.
On the other end, any new user will immediately benefit from more practical
default values.
> >
> > In the end, my biggest concern is the ssh socket timeout, since it is
the most tricky to configure and a lot of sample code I found on the
internet did not mention this timeout.  If you are hesitating, I would at
least set a finite default for that one.
> >
>
> Gaspard
>
> As of 4.4 HttpClient uses connect timeout value for SSL handshake by
> default. I hope this should be enough to address your biggest concern.
>
> I am a bit hesitant to set socket and connect timeouts to a positive
> value by default as JRE default timeout values are 0 (no timeout).

I think the JRE will never change that behavior due to compatibility.

I think it is OK for us to use timeouts in version 5 to non-infinite
values. It is just odd to have a default config that can cause an app to
appear to hang by default.

Gary

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

--047d7b3a8bfacfaa900529257fe6--