On Jan 12, 2016 8:06 AM, "Oleg Kalnichevski" <[email protected]> wrote: > > 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).
I think the JRE will never change that behavior due to compatibility. I think it is OK for us to use timeouts in version 5 to non-infinite values. It is just odd to have a default config that can cause an app to appear to hang by default. Gary > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
