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:

    *   retry

    *   retry-constant

    *   retry-exponential

    *   retry-fibonacci

    *   retry-lild

    *   retry-limd

    *   retry-mild

    *   retry-mimd

    *   show-backoff-delays

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).

    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_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).

    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_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).

    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_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).

    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_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).

    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_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).

    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_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).

    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)

  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).

    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)

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-AlgorithmBackoffU
    tils>

    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.

SEE ALSO
    Algorithm::Backoff::Exponential.

    Algorithm::Backoff::LIMD.

    Algorithm::Backoff::Constant.

    Algorithm::Backoff::LILD.

    Algorithm::Backoff::Fibonacci.

    Algorithm::Backoff::MILD.

    Algorithm::Backoff::MIMD.

    Algorithm::Backoff

AUTHOR
    perlancar <perlancar@cpan.org>

COPYRIGHT AND LICENSE
    This software is copyright (c) 2019 by perlancar@cpan.org.

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

