Let's talk retries

[Menno Smits]

On 9 August 2016 at 12:22, Katherine Cox-Buday <
katherine.cox-buday at canonical.com> wrote:

>
> To implement this, I do something like this:
>
> args := retry.CallArgs{
>     Func: func() error {
>         // Body of my loop
>     },
>     BackoffFunc: func(delay time.Duration, attempt int) time.Duration {
>         if attempt == 1 {
>             return delay
>         }
>         return delay * factor
>     },
>
>
Note that for BackoffFunc there is already one canned function in the retry
package for the common case of doubling the retry delay (DoubleDelay). It
might be nice to add a few more standard backoff functions and/or a factory
for multiplicative delays like this to remove the need for a little bit of
boilerplate in every use of retry.Call.



> Functionally, what's in juju/retry is fine; and I can stuff anything I
> want into the function. It just feels a little odd to use in that I must
> put the body of my loop in a function, and I dislike that the CallArgs
> struct attempts to encapsulate a bunch of different scenarios.
>

BackoffTick has a certain elegance but I still prefer retry.Call because it
makes it harder to get things wrong. The CallArgs struct helps to remind
the developer of the things they should be thinking about whereas with
BackoffTick it's easy to forget about some aspect (e.g. the need for a
cancellation channel).

retry.Call also has the advantage of already being able to do the job and
already being in use.


> Also, is it on the roadmap to address the inconsitant retries throughout
> Juju? I almost used utils.BackoffTimer until I started looking deeper. I'm
> going to submit a PR to flag it as deprecated.
>

That would be good to do IMO.

Cheers,
Menno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160809/daa00f8a/attachment.html>