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. Gaspard > On Jan 6, 2016, at 8:27 AM, Oleg Kalnichevski <ol...@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-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
