On Sun, 2016-01-10 at 22:51 -0500, Gaspard Petit wrote: > 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 As of 4.4 HttpClient uses connect timeout value for SSL handshake by default. I hope this should be enough to address your biggest concern. I am a bit hesitant to set socket and connect timeouts to a positive value by default as JRE default timeout values are 0 (no timeout). Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
