-
Notifications
You must be signed in to change notification settings - Fork 29
Add an optional retry delay #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
By specifying an optional 3rd parameter (in seconds), you can cause a small delay between retries. This can be useful to avoid the perception of flooding.
I'm inclined to keep this lib as simple and small as possible. I am however considering adding a delay, or even a generic onError mechanism. |
+1 for usleep. Some things fix themselves rather quickly :) Third param could accept int microseconds for delay or a callable for custom onError? |
👍 for keeping this flexible. While the general case will be for a fixed delay, there are cases where you might want to implement an exponential backoff (e.g. doctrine/mongodb#120 (comment)) or some other logic. |
Yeah, I like the callable idea. Not sure about calling it onError, though - maybe onRetry? |
Here's my WIP proposal btw https://github.com/igorw/retry/compare/on-error |
@beryllium or maybe, |
@igorw: Whipped up the following, which I think would work nicely with the <?php
class ExponentialBackoff
{
private $invoked = 0;
private $slotTimeUsec;
public function __construct($slotTimeUsec)
{
$this->slotTimeUsec = (int) $slotTimeUsec;
}
public function __invoke()
{
usleep(rand(0, (2 << (++$this->invoked - 1)) - 1) * $this->slotTimeUsec);
}
} Missing bounds detection for the bit-shifting (probably to cap it at |
By specifying an optional 3rd parameter (in seconds), you can cause a small delay between retries. This can be useful to avoid the perception of flooding.