BackoffEntry: Add the option to always use a delay.

BackoffEntry:  Add the option to use a delay between requests
before backoff starts due to failures, for use with captive
portal code.

R=joi@chroimium.org
BUG=87100, 115487
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=133792

[Sergey Ulanov, 2012-04-24 19:29:21]

remoting/ - LGTM

[Jói, 2012-04-24 20:51:19]

LGTM

http://codereview.chromium.org/10173005/diff/1010/remoting/host/chromoting_ho...
File remoting/host/chromoting_host.cc (right):

http://codereview.chromium.org/10173005/diff/1010/remoting/host/chromoting_ho...
remoting/host/chromoting_host.cc:59: false,
Did you mean to set this to true and update the comment?  If not, what was the
motivation for this change?  (I like the change anyway)

[Jói, 2012-04-24 20:52:40]

(You will also need OWNERS approval from net/OWNERS)

On Tue, Apr 24, 2012 at 8:51 PM,  <joi@chromium.org> wrote:
> LGTM
>
>
>
http://codereview.chromium.org/10173005/diff/1010/remoting/host/chromoting_ho...
> File remoting/host/chromoting_host.cc (right):
>
>
http://codereview.chromium.org/10173005/diff/1010/remoting/host/chromoting_ho...
> remoting/host/chromoting_host.cc:59: false,
> Did you mean to set this to true and update the comment?  If not, what
> was the motivation for this change?  (I like the change anyway)
>
> http://codereview.chromium.org/10173005/

[mmenke, 2012-04-24 21:05:24]

Thanks for the reviews, both of you.

http://codereview.chromium.org/10173005/diff/1010/remoting/host/chromoting_ho...
File remoting/host/chromoting_host.cc (right):

http://codereview.chromium.org/10173005/diff/1010/remoting/host/chromoting_ho...
remoting/host/chromoting_host.cc:59: false,
On 2012/04/24 20:51:20, Jói wrote:
> Did you mean to set this to true and update the comment?  If not, what was the
> motivation for this change?  (I like the change anyway)

The motivation is my unlanded captive portal detection CL.  Nothing to do with
this file.  We want to repeatedly request the same file for checking for captive
portals, but since a lot of things that trigger the captive portal check may
happen in a row (A bunch of network errors), we want a pretty significant
timeout between checks, normally (Currently 10 minutes, when not behind a
captive portal, though we may play with that significantly, and maybe reset the
failure count on network changes).

If we get the same result too often, we then want to start exponential backoff,
so we don't hammer servers when the check is consistently getting triggered, but
our captive portal state isn't changing.

[mmenke, 2012-04-24 21:07:26]

On 2012/04/24 20:52:40, Jói wrote:
> (You will also need OWNERS approval from net/OWNERS)

Thanks, but I'm a net OWNER, so it's not necessary.  :)

[commit-bot: I haz the power, 2012-04-24 21:09:28]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mmenke@chromium.org/10173005/1010

[Jói, 2012-04-24 22:15:37]

SGTM, thanks Matt.

On Tue, Apr 24, 2012 at 9:05 PM,  <mmenke@chromium.org> wrote:
> Thanks for the reviews, both of you.
>
>
>
>
http://codereview.chromium.org/10173005/diff/1010/remoting/host/chromoting_ho...
> File remoting/host/chromoting_host.cc (right):
>
>
http://codereview.chromium.org/10173005/diff/1010/remoting/host/chromoting_ho...
> remoting/host/chromoting_host.cc:59: false,
> On 2012/04/24 20:51:20, Jói wrote:
>>
>> Did you mean to set this to true and update the comment?  If not, what
>
> was the
>>
>> motivation for this change?  (I like the change anyway)
>
>
> The motivation is my unlanded captive portal detection CL.  Nothing to
> do with this file.  We want to repeatedly request the same file for
> checking for captive portals, but since a lot of things that trigger the
> captive portal check may happen in a row (A bunch of network errors), we
> want a pretty significant timeout between checks, normally (Currently 10
> minutes, when not behind a captive portal, though we may play with that
> significantly, and maybe reset the failure count on network changes).
>
> If we get the same result too often, we then want to start exponential
> backoff, so we don't hammer servers when the check is consistently
> getting triggered, but our captive portal state isn't changing.
>
> http://codereview.chromium.org/10173005/

[commit-bot: I haz the power, 2012-04-24 22:48:12]

Change committed as 133792