You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Gaspard Petit <ga...@gmail.com> on 2016/01/06 03:52:45 UTC
Default timeouts
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
Re: Default timeouts
Posted by Gary Gregory <ga...@gmail.com>.
On Jan 12, 2016 8:06 AM, "Oleg Kalnichevski" <ol...@apache.org> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
Re: Default timeouts
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2016-01-13 at 13:35 +0000, Gaspard Petit wrote:
> Hi Oleg,
>
> This solution is satisfactory for the use cases I have in mind and I am
> convinced it will improve the development experience with HttpClient.
>
> Thanks again,
>
> Gaspard
Done in SVN trunk. Please review
http://svn.apache.org/viewvc?rev=1725089&view=rev
Oleg
> Le mer. 13 janv. 2016 à 04:58, Oleg Kalnichevski <ol...@apache.org> a
> écrit :
>
> > On Tue, 2016-01-12 at 15:36 -0700, Shawn Heisey wrote:
> > > On 1/12/2016 9:06 AM, Oleg Kalnichevski wrote:
> > > > 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).
> > >
> > > An opinion from someone of no consequence on this project:
> > >
> > > I think it would not be a big problem to have a nonzero default connect
> > > timeout, perhaps something between two and five minutes. It could
> > > possibly go as low as one minute.
> > >
> > > A nonzero default socket timeout is more of a *possible* problem. The
> > > majority of users would probably never notice, but it might be a very
> > > surprising and problematic change for some users.
> > >
> > > I'm not completely opposed to the idea, but my opinion about the default
> > > socket timeout value is that it should be relatively large, not less
> > > than five minutes, and perhaps 15 or 30.
> > >
> > > These changes would only be appropriate in the next *major* version, and
> > > it would need to be conspicuously documented, including the website,
> > > RELEASE_NOTES.txt, and perhaps other places. Even well-documented, it
> > > will catch some users by surprise, but this is true of nearly *any*
> > change.
> > >
> > > The values I have mentioned are much larger than the values Gaspard
> > > mentioned, but I believe it's better to have defaults that are longer
> > > than might be typical. Users who don't change the defaults will have a
> > > safety net to prevent endless hangs, but the larger defaults will be
> > > less likely to cause problems due to unexpected timeouts.
> > >
> > > The safest option is to not change the defaults, but as already
> > > mentioned on the thread, this can lead to situations where user programs
> > > completely hang.
> > >
> >
> > I agree.
> >
> > I suggest the following course of action:
> >
> > (*) enabled 3 minute connect timeout by default in 5.0. This should also
> > imply a 3 minute socket timeout for SSL handshakes.
> > (*) leave request socket timeout disabled by default for now
> > (*) ask for feedback in the next 5.0 release announcement.
> >
> > Oleg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Default timeouts
Posted by Gaspard Petit <ga...@gmail.com>.
Hi Oleg,
This solution is satisfactory for the use cases I have in mind and I am
convinced it will improve the development experience with HttpClient.
Thanks again,
Gaspard
Le mer. 13 janv. 2016 à 04:58, Oleg Kalnichevski <ol...@apache.org> a
écrit :
> On Tue, 2016-01-12 at 15:36 -0700, Shawn Heisey wrote:
> > On 1/12/2016 9:06 AM, Oleg Kalnichevski wrote:
> > > 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).
> >
> > An opinion from someone of no consequence on this project:
> >
> > I think it would not be a big problem to have a nonzero default connect
> > timeout, perhaps something between two and five minutes. It could
> > possibly go as low as one minute.
> >
> > A nonzero default socket timeout is more of a *possible* problem. The
> > majority of users would probably never notice, but it might be a very
> > surprising and problematic change for some users.
> >
> > I'm not completely opposed to the idea, but my opinion about the default
> > socket timeout value is that it should be relatively large, not less
> > than five minutes, and perhaps 15 or 30.
> >
> > These changes would only be appropriate in the next *major* version, and
> > it would need to be conspicuously documented, including the website,
> > RELEASE_NOTES.txt, and perhaps other places. Even well-documented, it
> > will catch some users by surprise, but this is true of nearly *any*
> change.
> >
> > The values I have mentioned are much larger than the values Gaspard
> > mentioned, but I believe it's better to have defaults that are longer
> > than might be typical. Users who don't change the defaults will have a
> > safety net to prevent endless hangs, but the larger defaults will be
> > less likely to cause problems due to unexpected timeouts.
> >
> > The safest option is to not change the defaults, but as already
> > mentioned on the thread, this can lead to situations where user programs
> > completely hang.
> >
>
> I agree.
>
> I suggest the following course of action:
>
> (*) enabled 3 minute connect timeout by default in 5.0. This should also
> imply a 3 minute socket timeout for SSL handshakes.
> (*) leave request socket timeout disabled by default for now
> (*) ask for feedback in the next 5.0 release announcement.
>
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Default timeouts
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2016-01-12 at 15:36 -0700, Shawn Heisey wrote:
> On 1/12/2016 9:06 AM, Oleg Kalnichevski wrote:
> > 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).
>
> An opinion from someone of no consequence on this project:
>
> I think it would not be a big problem to have a nonzero default connect
> timeout, perhaps something between two and five minutes. It could
> possibly go as low as one minute.
>
> A nonzero default socket timeout is more of a *possible* problem. The
> majority of users would probably never notice, but it might be a very
> surprising and problematic change for some users.
>
> I'm not completely opposed to the idea, but my opinion about the default
> socket timeout value is that it should be relatively large, not less
> than five minutes, and perhaps 15 or 30.
>
> These changes would only be appropriate in the next *major* version, and
> it would need to be conspicuously documented, including the website,
> RELEASE_NOTES.txt, and perhaps other places. Even well-documented, it
> will catch some users by surprise, but this is true of nearly *any* change.
>
> The values I have mentioned are much larger than the values Gaspard
> mentioned, but I believe it's better to have defaults that are longer
> than might be typical. Users who don't change the defaults will have a
> safety net to prevent endless hangs, but the larger defaults will be
> less likely to cause problems due to unexpected timeouts.
>
> The safest option is to not change the defaults, but as already
> mentioned on the thread, this can lead to situations where user programs
> completely hang.
>
I agree.
I suggest the following course of action:
(*) enabled 3 minute connect timeout by default in 5.0. This should also
imply a 3 minute socket timeout for SSL handshakes.
(*) leave request socket timeout disabled by default for now
(*) ask for feedback in the next 5.0 release announcement.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Default timeouts
Posted by Shawn Heisey <ap...@elyograg.org>.
On 1/12/2016 9:06 AM, Oleg Kalnichevski wrote:
> 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).
An opinion from someone of no consequence on this project:
I think it would not be a big problem to have a nonzero default connect
timeout, perhaps something between two and five minutes. It could
possibly go as low as one minute.
A nonzero default socket timeout is more of a *possible* problem. The
majority of users would probably never notice, but it might be a very
surprising and problematic change for some users.
I'm not completely opposed to the idea, but my opinion about the default
socket timeout value is that it should be relatively large, not less
than five minutes, and perhaps 15 or 30.
These changes would only be appropriate in the next *major* version, and
it would need to be conspicuously documented, including the website,
RELEASE_NOTES.txt, and perhaps other places. Even well-documented, it
will catch some users by surprise, but this is true of nearly *any* change.
The values I have mentioned are much larger than the values Gaspard
mentioned, but I believe it's better to have defaults that are longer
than might be typical. Users who don't change the defaults will have a
safety net to prevent endless hangs, but the larger defaults will be
less likely to cause problems due to unexpected timeouts.
The safest option is to not change the defaults, but as already
mentioned on the thread, this can lead to situations where user programs
completely hang.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Default timeouts
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Default timeouts
Posted by Gaspard Petit <ga...@gmail.com>.
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-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Default timeouts
Posted by Oleg Kalnichevski <ol...@apache.org>.
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-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org