hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Default timeouts
Date Wed, 06 Jan 2016 13:27:14 GMT
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


Mime
View raw message