Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: Default timeouts
From: Gaspard Petit <gaspardpetit@gmail.com>
In-Reply-To: <1452086834.15625.3.camel@apache.org>
Date: Sun, 10 Jan 2016 22:51:18 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B94B260-077D-42FF-BF54-2445E9F44F93@gmail.com>
References: <2356A8A3-B4FA-4DD4-A190-662DAB0DCDC6@gmail.com>
 <1452086834.15625.3.camel@apache.org>
To: HttpComponents Project <dev@hc.apache.org>

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


> On Jan 6, 2016, at 8:27 AM, Oleg Kalnichevski <olegk@apache.org> =
wrote:
>=20
> On Tue, 2016-01-05 at 21:52 -0500, Gaspard Petit wrote:
>> Hello,
>>=20
>> This is a follow up of the comment I posted on =
https://issues.apache.org/jira/browse/HTTPCLIENT-1478
>>=20
>> My understanding is that there are 4 timeouts used in the =
HttpClient=E2=80=99s API :
>>=20
>> a per request socket timeout, configured using =
RequestConfig.Builder.setSocketTimeout which affects the io operations =
of the socket used to transfer data over http;
>> a per request connection timeout, configured using =
RequestConfig.Builder.setConnectTimeout, which affects the establishment =
of the connection with the web server;
>> a per request pool timeout, configured using =
RequestConfig.Builder.setConnectionRequestTimeout, which affects the =
maximum time to wait for a client to be available in the client pool. =
This one defaults to the value set with =
RequestConfig.Builder.setConnectTimeout.
>> a per connection socket timeout, used for ssl tunnelling, configured =
using SocketConfig.custom().setSoTimeout, which affects the timeout for =
establishing the ssl tunnel connection.
>>=20
>> My understanding is that all these timeouts have default value of =
no-timeout.
>>=20
>> There are numerous threads on the internet about people falling into =
the trap of not setting a default timeout only to discover, days later, =
that their app is stuck - a simple google search for "httpclient =
stuck=E2=80=9D will convince you.
>>=20
>> Among these posts, some people have been setting timeout values for =
connection, but find out the hard way that SSL connections have their =
own timeout setting.
>>=20
>> I am writing to suggest that the default timeout values be changed =
for something long but not infinite.  The current infinite value make =
the API more complex to use since HTTPClients.createDefault() - which =
should provide a client with recommended settings, returns instead a =
client that is dangerous to use (i.e. it may hang infinitely).
>>=20
>> It seems to me that all the above timeout, except the =
connectionRequestTimeout, should have finite timeout by default.
>>=20
>> While we are in the topic of defaults, I would like to bring up the =
default values for the PoolingHttpClientConnectionManager. Even the =
tutorial for HttpComponents mentions that the default limits are low: =
"Per default this implementation will create no more than 2 concurrent =
connections per given route and no more 20 connections in total. For =
many real-world applications these limits may prove too constraining, =
especially if they use HTTP as a transport protocol for their =
services.=E2=80=9D =
(https://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.htm=
l).
>>=20
>> This is also discussed in numerous posts on the internet.  Why not =
make HttpClient ready for "real-world applications=E2=80=9D by default =
and use 200 max connections, 20 max per route?
>>=20
>=20
> Hi Gaspard
>=20
> This limit has already been relaxed in 5.0 (trunk). The trouble with
> timeouts is that their values tend to be highly application specific. =
I
> am not sure what defaults could be considered 'real-world applicable'.=20=

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


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