Skip to content
This repository has been archived by the owner on Jun 21, 2023. It is now read-only.

Alternate API for building RetryConfig #76

Open
raghavan20 opened this issue Aug 28, 2018 · 3 comments
Open

Alternate API for building RetryConfig #76

raghavan20 opened this issue Aug 28, 2018 · 3 comments
Assignees
Milestone

Comments

@raghavan20
Copy link

Currently, the RetryConfigBuilder has lot of options. Many of those options are exclusive and belong to logical groups. I was wondering whether we could simplify the API by having smaller group of builders; this might help users to browse the available options reasonably easier. Also please provide any alternate suggestions.

    //    **Exception retry config*
    ExceptionRetryConfig exceptionRetryConfig = exceptionRetryConfigBuilder()
                .failForAnyException()
                .matchOnCause()
                .build()
    ExceptionRetryConfig exceptionRetryConfig = exceptionRetryConfigBuilder()
                .matchExceptions(mex1, mex2)
                .excludeExceptions(ex1, ex2)
                .matchOnCause()
                .build()
    ExceptionRetryConfig exceptionRetryConfig = exceptionRetryConfigBuilder()
                .matchExceptions(mex1, mex2)
                .excludeExceptions(ex1, ex2)
                .matchOnCause()
                .onExceptionExecute(ex -> {})
                .build()


    //    **Timing retry config: Option 1**
    TimingRetryConfig timingRetryConfig = timingRetryConfigBuilder().maxTries(5).build()
    TimingRetryConfig timingRetryConfig = timingRetryConfigBuilder().retryIndefinitely().build()
    TimingRetryConfig timingRetryConfig = timingRetryConfigBuilder().delayBetweenTries(5, SECONDS).build()
    TimingRetryConfig timingRetryConfig = timingRetryConfigBuilder().maxTries(5).build()

    //    **Timing retry config: Option 2**
    TimingRetryConfig timingRetryConfig = TimingRetryConfig.maxTries(5)
    TimingRetryConfig timingRetryConfig = TimingRetryConfig.retryIndefinitely()
    TimingRetryConfig timingRetryConfig = TimingRetryConfig.delayBetweenTries(5, SECONDS)

    //    **Choosing a backoff strategy**
    BackoffStrategy backoffStrategy = BackoffStrategy.FIBONACCI
    BackoffStrategy backoffStrategy = BackoffStrategy.fixedBackoff5Tries10Sec()


    //    **Building the complete immutable RetryConfig**
    RetryConfig retryConfig = retryConfigBuilder()
      .exceptionRetryConfig(exceptionRetryConfig)
      .retryOnReturnValue(value)
      .timingRetryConfig(timingRetryConfig)
      .backoffStrategy(BackoffStrategy.XYZ)
      .build();
@elennick
Copy link
Owner

I agree with the issue, the config builder definitely has grown to have a lot of options with some being required, some being optional, some being mutually exclusive, etc. Until now I've tried to get around that using the builder validation to indicate when someone tries to build a config in an invalid state and via examples/documentation. I'd be ok trying out some form of what you laid out above with sub builders... do you want to try prototyping something so we can see a concrete example and see how it feels?

@elennick
Copy link
Owner

Also it might be worth checking out some other libraries to see how they handle streamlining their configuration/setup... it's possible we could get some ideas from what others have done. I have a list of other Java retry libraries at the bottom of the README you can use to start with if you're interested in that: https://github.com/elennick/retry4j#other-notes

@elennick elennick added this to the 0.16.0 milestone Aug 30, 2018
@raghavan20
Copy link
Author

I will make an attempt / POC this week

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants