New strategy about guava-retrying HOT 1 CLOSED

Currently, guava-retrying enables the customization of several distinct condition-checking interfaces for determining the retrying behavior: StopStrategy for explicit hard stop conditions, WaitStrategy for computing how long to wait between retry attempts, various Predicate evaluations on results and exceptions, and an integration with Guava's TimeLimiter. The included concrete implementations have been built around constructs that don't require global state or coordination among other bits of code in order to locally manage the retrying behavior for a single repeated function call.

A WaitStrategy is exposed as a nice little interface to create custom implementations of in your own applications that are built on top of this module. In order to keep this a very small interface footprint, I would not be excited to add chaining directly to the WaitStrategy in the RetryerBuilder, such as:

public static final Retryer<Object> COMPOSED_WAITS = RetryerBuilder.newBuilder()
        .withWaitStrategy(WaitStrategies.exponentialWait(100, 15, TimeUnit.SECONDS))
        .withWaitStrategy(WaitStrategies.fibonacciWait()
        .withStopStrategy(StopStrategies.stopAfterAttempt(10))
        .build();

I'm not sure that's exactly the route you had in mind, but just in case it was I wanted to save you some time. A more fun implementation might actually be a single join method in WaitStrategies where each strategy is combined together in such a way that they each add to the computed sleep value that is returned, such as:

public static WaitStrategy join(WaitStrategy... strategies)

In this way, we maintain the simplicity of the original interfacing while still adding the ability to express many more variants of WaitStrategy constructs. This is a very nice idea. Thanks for bringing it up and offering to help with it.

from guava-retrying.