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'. 


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

View raw message