lin_backoff is actually exponential

[bamorim]

Sorry to ask that question, but your lin_backoff is actually exponential. Actually, it yields the same numbers as exp_backoff if factor is 2.

iex(5)> Retry.DelayStreams.exp_backoff(10) |> Enum.take(10)
[20, 40, 80, 160, 320, 640, 1280, 2560, 5120, 10240]
iex(6)> Retry.DelayStreams.lin_backoff(10, 2) |> Enum.take(10)
[20, 40, 80, 160, 320, 640, 1280, 2560, 5120, 10240]

I can open a PR for this, but what I'd suggest is to just have the lin_backoff named exp_backoff and set the factor default to 2.

Then we can implement a lin_backoff like that:

  def lin_backoff(initial_delay, factor) do
    Stream.unfold(1, fn failures ->
      next_d = initial_delay + failures * factor
      {next_d, failures + 1}
    end)
  end

What do you think?

EDIT: fixed typo (last_delay -> initial_delay)

[Dzol]

We've observed this too 🙂 It'd be nice to see a fix for it

[safwank]

I'll look into it this weekend, fingers crossed.

[safwank]

@bamorim @Dzol Sorry it took me awhile, but here's what I'm thinking of doing.

• deprecate lin_backoff/2 to maintain backwards compatibility
• create a new function that actually returns linear delays

  def linear_backoff(delay \\ 100) do
  Stream.repeatedly(fn -> delay end)
  end

What do you think?

[bamorim]

@safwank then this is not a linear backoff but rather a constant backoff. IMO, linear should increase by a constant rate a, starting with some value b, so then it fits a curve a*x + b

[safwank]

@bamorim You're right. I'll rename the above function to const_backoff/1 and introduce a new one called linear_backoff/2 that really really :) returns a stream of linearly increasing delays.

[safwank]

@bamorim If you want, you can review the latest commits before I release v0.11.

[safwank]

Fixed in v0.11.