[DISCUSS] Failsafe Roadmap

[jhalterman]

This issue sketches out some of the past and future roadmap for Failsafe, and will be updated over time. Feel free to comment with suggestions.

3.x

• Phi accrural failure detection
• Backup requests
• Hedged retries

3.2

• Bulkhead

3.1

• Rate limiter

3.0

• Make some internal APIs more open Make some internal APIs more open #292
• Re-work Execution and AsyncExecution APIs Re-work Execution and AsyncExecution APIs #287
• Consider more explicit functional composition APIs Consider more explicit functional composition APIs #254
• Policy builders Policy builders #299

2.2:

• Cancellable async executions, backed by ForkJoinPool
• Timeout policy

For 2.0:

• Move to Java 8 as a requirement
• Add a ForkJoinPool.commonPool based Scheduler implementation
• Composable policy execution
  • Allow policies to be arbitrarily composed.
• Policy SPI
  • The SPI allows 3rd party policies to be plugged into Failsafe
  • The PolicyExecutor SPI allows policies to perform pre or post execution result handling
• Re-thinking event listeners - See [DISCUSS] Declaring event handlers globally or per policy #154
• Execution API improvements - See [DISCUSS] Execution API improvements #160
• Doc updates

[whiskeysierra]

• More Policy implementations including Bulkhead, RateLimiter, and Cache

What about backup requests or hedged requests?

• https://blog.acolyer.org/2015/01/15/the-tail-at-scale/
• https://github.com/zalando/riptide/tree/master/riptide-backup

[jhalterman]

@whiskeysierra Do you have another pointer for backup requests?

I suspect both of these would be specific to Http or other client/server technologies. Do you think there's a way to write policies for these in a way that's not specific to particular technologies and external dependencies?

[whiskeysierra]

Technically it's just a different flavor of retries. Retries right now are triggered by exceptions (or unacceptable results) while backup requests are somewhat like an early retry caused by latency/delay. Can apply to anything, not just HTTP.

[jhalterman]

Thanks - so to be clear, Riptide's backup requests are the same pattern as hedged requests?

[whiskeysierra]

Yes, backup requests and hedged requests are the same thing. Just different names.

[gelpenaddict]

Can you add a succeed on a Throwable? So that it keeps retrying if there is no exception and succeeds when you get a particular exception.

[jhalterman]

@gelpenaddict Yea, by default throwables are handled (treated as failures) but you can override that via handleIf to specify that you want to "handle" (retry) on certain results, else not (which means failures/exceptions will not be retried). Ex:

retryPolicy.handleIf((result, failure) -> result == someBadValue)

[timothybasanov]

Not a Contribution.

Not sure if I understand backup requests correctly, so I'm describing a behaviour that would be nice to have in my case:

Backup request is a bit different from a hedged one. It's more similar to an existing Fallback policy, but it starts its execution immediately, in parallel to the main request. Its results are only used when the main request fails. It may also need some retries/circuit breakers/fallbacks configured.

This is good for gradual service degradation where I can use a different and much less heavy request as a backup to the main request that may not be able to finish in time.

[jhalterman]

@timothybasanov Can you open an issue for backup requests?