exoscale.checkmate.condition
Conditioncljprotocol
retry?clj
(retry? this state)Returns true if we should retry upon error on this run
Returns true if we should retry upon error on this run
setup!clj
(setup! this state)Setups initial state before first run
Setups initial state before first run
update!clj
(update! this state)Update state after error
Update state after error
constant-backoff-delaysclj
(constant-backoff-delays ms)delayed-retriesclj
(delayed-retries delays)ErrorEffectcljprotocol
error-effect!clj
(error-effect! this state)Effect triggered upon error
Effect triggered upon error
exponential-backoff-delaysclj
(exponential-backoff-delays x)FailureEffectcljprotocol
failure-effect!clj
(failure-effect! this state)Effect triggered upon terminal failure
Effect triggered upon terminal failure
max-retriesclj
(max-retries max)progressive-backoff-delaysclj
(progressive-backoff-delays x)rate-limited-retriesclj
(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-onclj
(retry-on pred)Allow retries on (pred ret) -> true, useful to limit retries to a class of errors ex: (retry-on #(instance? TimeoutException %))
Allow retries on (pred ret) -> true, useful to limit retries to a class of errors ex: (retry-on #(instance? TimeoutException %))
SetupEffectcljprotocol
setup-effect!clj
(setup-effect! this state)Effect triggered before Run
Effect triggered before Run
SuccessEffectcljprotocol
success-effect!clj
(success-effect! this state)Effect triggered upon success
Effect triggered upon success
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close