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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to