You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was experimenting with Ticker and realized this structure could be a useful example.
ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
defer cancel()
for range ticker.C {
if result, err = operation(); err != nil {
log.Println(err, "will retry...")
select {
case <-ctx.Done():
break
case <-ticker.C:
// consume a waiting tick
continue
default:
continue
}
break
}
}
It ends up being similar to Retry behavior for slow fails, but incrementing the backoff twice for each operation. It's not always useful behavior, but it addresses the "operations that take a while to fail could run in quick succession" problem.
I also experimented with a non-blocking ticker by modifying Ticker.send:
select {
case t.c <- tick:
case <-t.stop:
return nil
default:
}
(also mentioned in #154)
This is more intuitive, as its tick rate is independent of slow fails, but ticks that occur during a slow fail are ignored.
I can make a PR if you're interested.
The text was updated successfully, but these errors were encountered:
I was experimenting with Ticker and realized this structure could be a useful example.
It ends up being similar to Retry behavior for slow fails, but incrementing the backoff twice for each operation. It's not always useful behavior, but it addresses the "operations that take a while to fail could run in quick succession" problem.
I also experimented with a non-blocking ticker by modifying Ticker.send:
(also mentioned in #154)
This is more intuitive, as its tick rate is independent of slow fails, but ticks that occur during a slow fail are ignored.
I can make a PR if you're interested.
The text was updated successfully, but these errors were encountered: