App-AlgorithmBackoffUtils
view release on metacpan or search on metacpan
than the previous timestamp), failure() will return 2 seconds. And
if you waited 4 seconds or more, failure() will return 0.
* delay => *ufloat*
Number of seconds to wait after a failure.
* delay_increment_on_failure => *float*
How much to add to previous delay, in seconds, upon failure (e.g.
5).
* delay_increment_on_success => *float*
How much to add to previous delay, in seconds, upon success (e.g.
-5).
* delay_multiple_on_failure => *ufloat*
How much to multiple previous delay, upon failure (e.g. 1.5).
* delay_multiple_on_success => *ufloat*
How much to multiple previous delay, upon success (e.g. 0.5).
* delay_on_success => *ufloat* (default: 0)
Number of seconds to wait after a success.
* exponent_base => *ufloat* (default: 2)
* initial_delay => *ufloat*
Initial delay for the first attempt after failure, in seconds.
* initial_delay1 => *ufloat*
Initial delay for the first attempt after failure, in seconds.
* initial_delay2 => *ufloat*
Initial delay for the second attempt after failure, in seconds.
* jitter_factor => *float*
How much to add randomness.
If you set this to a value larger than 0, the actual delay will be
between a random number between original_delay * (1-jitter_factor)
and original_delay * (1+jitter_factor). Jitters are usually added to
avoid so-called "thundering herd" problem.
The jitter will be applied to delay on failure as well as on
success.
* logs* => *array[str]*
List of failures or successes.
A list of 0's (to signify failure) or 1's (to signify success). Each
failure/success can be followed by ":TIMESTAMP" (unix epoch) or
":+SECS" (number of seconds after the previous log), or the current
timestamp will be assumed. Examples:
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1
(10 failures followed by 5 successes).
0 0:+2 0:+4 0:+6 1
(4 failures, 2 seconds apart, followed by immediate success.)
* max_actual_duration => *ufloat* (default: 0)
Maximum number of seconds for all of the attempts (0 means
unlimited).
If set to a positive number, will limit the number of seconds for
all of the attempts. This setting is used to limit the amount of
time you are willing to spend on a task. For example, when using the
Exponential strategy of initial_delay=3 and max_attempts=10, the
delays will be 3, 6, 12, 24, ... If failures are logged according to
the suggested delays, and max_actual_duration is set to 21 seconds,
then the third failure() will return -1 instead of 24 because 3+6+12
>= 21, even though max_attempts has not been exceeded.
* max_attempts => *uint* (default: 0)
Maximum number consecutive failures before giving up.
0 means to retry endlessly without ever giving up. 1 means to give
up after a single failure (i.e. no retry attempts). 2 means to retry
once after a failure. Note that after a success, the number of
attempts is reset (as expected). So if max_attempts is 3, and if you
fail twice then succeed, then on the next failure the algorithm will
retry again for a maximum of 3 times.
* max_delay => *ufloat*
Maximum delay time, in seconds.
* min_delay => *ufloat* (default: 0)
Maximum delay time, in seconds.
Special arguments:
* -dry_run => *bool*
Pass -dry_run=>1 to enable simulation mode.
Returns an enveloped result (an array).
First element (status) is an integer containing HTTP status code (200
means OK, 4xx caller error, 5xx function error). Second element (msg) is
a string containing error message, or 'OK' if status is 200. Third
element (payload) is optional, the actual result. Fourth element (meta)
is called result metadata and is optional, a hash that contains extra
information.
Return value: (any)
( run in 1.144 second using v1.01-cache-2.11-cpan-39bf76dae61 )