-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Learn how Resilience4j implements the Retry mechanism #4
Conversation
…try state machine
…nd the retry mechanism
… retry state machine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still need to clarify the different between a Retry
and a RetryConfig
|
||
Register a `Retry` instance in the `RetryRegistry` with a configuration: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still not clear what is the difference between a Retry
and a RetryConfig
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RetryConfig
represents the retry mechanism's behavior - policies - and is used to create a Retry
instance. Retry
is a thread-safe instance that holds the decoration logic and defines the async and sync contexts (i.e., state-holders), among other funcionalities (e.g., metrics, event-publishers).
A Retry
instance cannot be created without a custom or default RetryConfig
.
resilience4j/README.md
Outdated
> [!IMPORTANT] | ||
> If Javascript target is required, | ||
> a Kotlin Multiplatform implementation of the Retry mechanism cannot use synchronous [context](#context) because of the [single-threaded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My current opinion is that the library should only support coroutine contexts, i.e., allow interception of suspend
functions
Resolves: kresil/kresil#6