Dynamic configuration for retryConfig
See original GitHub issueResilience4j version: 1.5.0
Java version: 11
Thanks for raising a Resilience4j issue. Is there a way to dynamically update the interval function for the retry module.
Use case : I want to perform retries based on the RETRY_AFTER for my http requests. Currently the only way to configure retry is by pre-configuring an IntervalFunction on the retryConfig.
I have configured the resultPredicate
to look for the header to retry but I would want to retry based on the time specified in the header field.
I was wondering if there is a way to configure the RetryConfig for this scenario.
Issue Analytics
- State:
- Created 3 years ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
Retry - resilience4j
Create and configure Retry. You can provide a custom global RetryConfig. In order to create a custom global RetryConfig, you can use the...
Read more >Update the Resilience4J retry properties during runtime
I want to update the configuration properties of the register-retry1 retry either on runtime or within the code in a different place.
Read more >Retry with Spring Boot and Resilience4j - Reflectoring
We can configure the Resilience4j instances we need in Spring ... We don't have to create Resilience4j configuration object ( RetryConfig ) ...
Read more >Demonstrate retry configuration | Cloud Storage
Create the client configuration: auto options = google::cloud::Options{}; // Retries only idempotent operations. options.set<gcs::IdempotencyPolicyOption>(
Read more >RetryConfig (resilience4j-retry 1.7.1 API) - javadoc.io
declaration: package: io.github.resilience4j.retry, class: RetryConfig. ... static RetryConfig, ofDefaults(). Creates a default Retry configuration.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Sounds good to me, I also prefer a single function.
Sry for the late response.
Let’s say we have two functions:
intervalFunctionOnResult
andintervalFunctionOnException
.intervalFunctionOnResult
or as a fallbackinterfalFunction
is used.intervalFunctionOnException
or as a fallbackinterfalFunction
is used.But a single
intervalBiFunction
might allow to track/store in-memory which exceptions or results have occured and increase the timeout interval depending on the state / history.This is more difficult if we have two functions. I think because of this I prefer a single function.
interface IntervalBiFunction<T> extends BiFunction<Integer, Either<Exception, T>, Long>
What do you think?