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? Gaspard
