3 main states
You can for instance do:
;; will retry up to 3 times with a 1000ms delay between tries (cm/do! #(do-something) [(delayed-retries (constant-backoff-delays 1000)) (max-retries 3)])
3 main states * success (all good) * error (bad, potentially retry) * failure (terminal failure) - Conditions control if we should retry and how to setup the state at first call, and how to update the state upon failures (inc retry counter for instance). Conditions are in effect, composable and should remain pure (state in/out). You can for instance do: ;; will retry up to 3 times with a 1000ms delay between tries (cm/do! #(do-something) [(delayed-retries (constant-backoff-delays 1000)) (max-retries 3)]) - Effects can apply side effects at various stages (ex sleep, update state machine), they are purely for io, as opposed to Conditions
(constant-backoff-delays ms)
(delays coll)
(exponential-backoff-delays x)
(fail-on pred)
Set to failed on (pred ret) -> true Similar to retry-on, the other way around. Fails on match.
Set to failed on (pred ret) -> true Similar to retry-on, the other way around. Fails on match.
(max-retries max)
(progressive-backoff-delays x)
(rate-limited-retries
{:keys [max-errors error-rate exception]
:or {max-errors 10
error-rate 1000
exception (fn [condition state]
(ex-info "Rejected execution, max rate reached"
{:type :exoscale.ex/busy
:exoscale.checkmate/condition condition
:exoscale.checkmate/state state}))}})
!! This condition should be shared for all runner calls, since it's stateful
Only allows a max rate of errors until it plain rejects calls until rate can be satisfied again:
Example:
max-errors : 10 error-rate : 1000ms
Allows up to 10 successive errors, upon token exhaustion will only allow 1 error per second in burst, until it fills again to 10.
So this allows burst'iness up to a point.
If you create a lot or rate-limited-retries conditions you need to remember to async/close! the associated chan, or pass it as argument. The chan is also available via Condition state, in case you want to enable temporary burst'iness, early flush or closing
!! This condition should be shared for all runner calls, since it's stateful Only allows a max rate of errors until it plain rejects calls until rate can be satisfied again: Example: max-errors : 10 error-rate : 1000ms Allows up to 10 successive errors, upon token exhaustion will only allow 1 error per second in burst, until it fills again to 10. So this allows burst'iness up to a point. If you create a lot or rate-limited-retries conditions you need to remember to async/close! the associated chan, or pass it as argument. The chan is also available via Condition state, in case you want to enable temporary burst'iness, early flush or closing
(retry-on x)
Allow retries on (pred ret) -> true, useful to limit retries to a
class of errors ex: (retry-on #(instance? TimeoutException %)). x
can be a function, a Class name (ex: some exception type), or a
keyword in that case it will match (exoscale.ex/type? x %).
Allow retries on (pred ret) -> true, useful to limit retries to a class of errors ex: (retry-on #(instance? TimeoutException %)). `x` can be a function, a Class name (ex: some exception type), or a keyword in that case it will match (exoscale.ex/type? x %).
(retry-on* pred)
like retry-on, but runs on the whole state instead of just result
like retry-on, but runs on the whole state instead of just result
(run f conditions)
(run f conditions opts)
Synchronous runner, take function f
and runs it.
Upon error will check Conditions passed as arguments to know if it
warrants a retry, otherwise it triggers a failure and rethrows the
last error.
At every stage hooks
are invoked, and potentially Effects from
Conditions.
hook
: map of allow to setup event at various stages (logging, reporting)conditions
: sequence of Conditions to be usedSynchronous runner, take function `f` and runs it. Upon error will check Conditions passed as arguments to know if it warrants a retry, otherwise it triggers a failure and rethrows the last error. At every stage `hooks` are invoked, and potentially Effects from Conditions. * `hook`: map of allow to setup event at various stages (logging, reporting) * `conditions`: sequence of Conditions to be used
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close