NAME

App::AlgorithmBackoffUtils - Utilities related to Algorithm::Backoff

VERSION

This document describes version 0.003 of App::AlgorithmBackoffUtils (from Perl distribution App-AlgorithmBackoffUtils), released on 2019-06-08.

DESCRIPTION

This distributions provides the following command-line utilities:

FUNCTIONS

retry

Usage:

 retry(%args) -> [status, msg, payload, meta]

Retry a command with custom backoff algorithm.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

algorithm* => str

Backoff algorithm.
command* => array[str]
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger 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.
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.
retry_on => str

Comma-separated list of exit codes that should trigger retry.

By default, all non-zero exit codes will trigger retry.
skip_delay => true

Do not delay at all.

Useful for testing, along with --dry-run, when you just want to see how the retries are done (the number of retries, along with the number of seconds of delays) by seeing the log messages, without actually delaying.
success_on => str

Comma-separated list of exit codes that mean success.

By default, only exit code 0 means success.

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)

retry_constant

Usage:

 retry_constant(%args) -> [status, msg, payload, meta]

Retry a command with constant delay backoff.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

command* => array[str]
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger 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_on_success => ufloat (default: 0)

Number of seconds to wait after a success.
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.
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.
retry_on => str

Comma-separated list of exit codes that should trigger retry.

By default, all non-zero exit codes will trigger retry.
skip_delay => true

Do not delay at all.

Useful for testing, along with --dry-run, when you just want to see how the retries are done (the number of retries, along with the number of seconds of delays) by seeing the log messages, without actually delaying.
success_on => str

Comma-separated list of exit codes that mean success.

By default, only exit code 0 means success.

Special arguments:

-dry_run => bool

Pass -dry_run=>1 to enable simulation mode.

Returns an enveloped result (an array).

Return value: (any)

retry_exponential

Usage:

 retry_exponential(%args) -> [status, msg, payload, meta]

Retry a command with exponential backoff.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

command* => array[str]
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger than the previous timestamp), failure() will return 2 seconds. And if you waited 4 seconds or more, failure() will return 0.
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.
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.
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.
retry_on => str

Comma-separated list of exit codes that should trigger retry.

By default, all non-zero exit codes will trigger retry.
skip_delay => true

Do not delay at all.

Useful for testing, along with --dry-run, when you just want to see how the retries are done (the number of retries, along with the number of seconds of delays) by seeing the log messages, without actually delaying.
success_on => str

Comma-separated list of exit codes that mean success.

By default, only exit code 0 means success.

Special arguments:

-dry_run => bool

Pass -dry_run=>1 to enable simulation mode.

Returns an enveloped result (an array).

Return value: (any)

retry_fibonacci

Usage:

 retry_fibonacci(%args) -> [status, msg, payload, meta]

Retry a command with fibonacci backoff.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

command* => array[str]
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger than the previous timestamp), failure() will return 2 seconds. And if you waited 4 seconds or more, failure() will return 0.
delay_on_success => ufloat (default: 0)

Number of seconds to wait after a success.
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.
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.
retry_on => str

Comma-separated list of exit codes that should trigger retry.

By default, all non-zero exit codes will trigger retry.
skip_delay => true

Do not delay at all.

Useful for testing, along with --dry-run, when you just want to see how the retries are done (the number of retries, along with the number of seconds of delays) by seeing the log messages, without actually delaying.
success_on => str

Comma-separated list of exit codes that mean success.

By default, only exit code 0 means success.

Special arguments:

-dry_run => bool

Pass -dry_run=>1 to enable simulation mode.

Returns an enveloped result (an array).

Return value: (any)

retry_lild

Usage:

 retry_lild(%args) -> [status, msg, payload, meta]

Retry a command with LILD (linear increase, linear decrease) backoff.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

command* => array[str]
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger than the previous timestamp), failure() will return 2 seconds. And if you waited 4 seconds or more, failure() will return 0.
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).
initial_delay* => ufloat

Initial delay for the first 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.
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.
retry_on => str

Comma-separated list of exit codes that should trigger retry.

By default, all non-zero exit codes will trigger retry.
skip_delay => true

Do not delay at all.

Useful for testing, along with --dry-run, when you just want to see how the retries are done (the number of retries, along with the number of seconds of delays) by seeing the log messages, without actually delaying.
success_on => str

Comma-separated list of exit codes that mean success.

By default, only exit code 0 means success.

Special arguments:

-dry_run => bool

Pass -dry_run=>1 to enable simulation mode.

Returns an enveloped result (an array).

Return value: (any)

retry_limd

Usage:

 retry_limd(%args) -> [status, msg, payload, meta]

Retry a command with LIMD (linear increase, multiplicative decrease) backoff.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

command* => array[str]
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger than the previous timestamp), failure() will return 2 seconds. And if you waited 4 seconds or more, failure() will return 0.
delay_increment_on_failure* => float

How much to add to previous delay, in seconds, upon failure (e.g. 5).
delay_multiple_on_success* => ufloat

How much to multiple previous delay, upon success (e.g. 0.5).
initial_delay* => ufloat

Initial delay for the first 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.
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.
retry_on => str

Comma-separated list of exit codes that should trigger retry.

By default, all non-zero exit codes will trigger retry.
skip_delay => true

Do not delay at all.

Useful for testing, along with --dry-run, when you just want to see how the retries are done (the number of retries, along with the number of seconds of delays) by seeing the log messages, without actually delaying.
success_on => str

Comma-separated list of exit codes that mean success.

By default, only exit code 0 means success.

Special arguments:

-dry_run => bool

Pass -dry_run=>1 to enable simulation mode.

Returns an enveloped result (an array).

Return value: (any)

retry_mild

Usage:

 retry_mild(%args) -> [status, msg, payload, meta]

Retry a command with MILD (multiplicative increase, linear decrease) backoff.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

command* => array[str]
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger than the previous timestamp), failure() will return 2 seconds. And if you waited 4 seconds or more, failure() will return 0.
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).
initial_delay* => ufloat

Initial delay for the first 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.
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.
retry_on => str

Comma-separated list of exit codes that should trigger retry.

By default, all non-zero exit codes will trigger retry.
skip_delay => true

Do not delay at all.

Useful for testing, along with --dry-run, when you just want to see how the retries are done (the number of retries, along with the number of seconds of delays) by seeing the log messages, without actually delaying.
success_on => str

Comma-separated list of exit codes that mean success.

By default, only exit code 0 means success.

Special arguments:

-dry_run => bool

Pass -dry_run=>1 to enable simulation mode.

Returns an enveloped result (an array).

Return value: (any)

retry_mimd

Usage:

 retry_mimd(%args) -> [status, msg, payload, meta]

Retry a command with MIMD (multiplicative increase, multiplicative decrease) backoff.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

command* => array[str]
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger than the previous timestamp), failure() will return 2 seconds. And if you waited 4 seconds or more, failure() will return 0.
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).
initial_delay* => ufloat

Initial delay for the first 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.
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.
retry_on => str

Comma-separated list of exit codes that should trigger retry.

By default, all non-zero exit codes will trigger retry.
skip_delay => true

Do not delay at all.

Useful for testing, along with --dry-run, when you just want to see how the retries are done (the number of retries, along with the number of seconds of delays) by seeing the log messages, without actually delaying.
success_on => str

Comma-separated list of exit codes that mean success.

By default, only exit code 0 means success.

Special arguments:

-dry_run => bool

Pass -dry_run=>1 to enable simulation mode.

Returns an enveloped result (an array).

Return value: (any)

show_backoff_delays

Usage:

 show_backoff_delays(%args) -> [status, msg, payload, meta]

Show backoff delays.

This function is not exported.

This function supports dry-run operation.

Arguments ('*' denotes required arguments):

algorithm* => str

Backoff algorithm.
consider_actual_delay => bool (default: 0)

Whether to consider actual delay.

If set to true, will take into account the actual delay (timestamp difference). For example, when using the Constant strategy of delay=2, you log failure() again right after the previous failure() (i.e. specify the same timestamp). failure() will then return ~2+2 = 4 seconds. On the other hand, if you waited 2 seconds before calling failure() again (i.e. specify the timestamp that is 2 seconds larger 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).

Return value: (any)

HOMEPAGE

Please visit the project's homepage at https://metacpan.org/release/App-AlgorithmBackoffUtils.

SOURCE

Source repository is at https://github.com/perlancar/perl-App-AlgorithmBackoffUtils.

BUGS

Please report any bugs or feature requests on the bugtracker website https://rt.cpan.org/Public/Dist/Display.html?Name=App-AlgorithmBackoffUtils

When submitting a bug or request, please include a test-file or a patch to an existing test-file that illustrates the bug or desired feature.

AUTHOR

perlancar <perlancar@cpan.org>

COPYRIGHT AND LICENSE

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

To install App::AlgorithmBackoffUtils, copy and paste the appropriate command in to your terminal.

cpanm

cpanm App::AlgorithmBackoffUtils

CPAN shell

perl -MCPAN -e shell
install App::AlgorithmBackoffUtils

For more information on module installation, please visit the detailed CPAN module installation guide.

	Global
`s`	Focus search bar
`?`	Bring up this help dialog

	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)

	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse

	Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)

NAME

VERSION

DESCRIPTION

FUNCTIONS

retry

retry_constant

retry_exponential

retry_fibonacci

retry_lild

retry_limd

retry_mild

retry_mimd

show_backoff_delays

HOMEPAGE

SOURCE

BUGS

SEE ALSO

AUTHOR

COPYRIGHT AND LICENSE

Module Install Instructions