hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gaspard Petit <gaspardpe...@gmail.com>
Subject Re: Default timeouts
Date Mon, 11 Jan 2016 03:51:18 GMT
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.


> On Jan 6, 2016, at 8:27 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Tue, 2016-01-05 at 21:52 -0500, Gaspard Petit wrote:
>> Hello,
>> This is a follow up of the comment I posted on https://issues.apache.org/jira/browse/HTTPCLIENT-1478
>> My understanding is that there are 4 timeouts used in the HttpClient’s API :
>> 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.
>> My understanding is that all these timeouts have default value of no-timeout.
>> 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” will convince you.
>> 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.
>> 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).
>> It seems to me that all the above timeout, except the connectionRequestTimeout, should
have finite timeout by default.
>> 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.” (https://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html).
>> This is also discussed in numerous posts on the internet.  Why not make HttpClient
ready for "real-world applications” by default and use 200 max connections, 20 max per route?
> Hi Gaspard
> 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'. 
> 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

View raw message