Did you evaluate javaslang-circuitbreaker

[RobWin]

Hi,

did you evaluate https://github.com/RobWin/javaslang-circuitbreaker ? The implementation is different, because it is using higher order functions to enhance any functional interface, lambda expression or method reference with additional functionality.

[Emily-Jiang]

Thank you Robert for sharing another library of fault tolerance! I took a quick look at it. It is kind of similar to Failsafe. It seems it does not deal with async executions. Can you review the APIs proposed and assess whether the javaslang-circuitbreaker can implement the APIs? Please make any concrete suggestions so that we can discuss further. It seems javaslang-circuitbreaker does not mention bulkhead or Timeout at all.

[RobWin]

Hi,

the implementation and design is different to Failsafe. We do not wrap method calls and provide methods like FailSafe.get, run or runAsync. For example

String result = Failsafe.with(cirucitBreaker).get(() -> backendService.doSomething());

We use higher order functions to enhance any functional interface, lambda expression or method reference (similar to the Decorator Pattern) lazily and do not invoke them.

Callable<String> supplier = () -> backendService.doSomething();
Callable<String> decorated = CircuitBreakee.decorateCallable(circuitBreaker, supplier);

You can use the decorated Callable whereever you like, for example:

CompletableFuture<String> future = CompletableFuture.supplyAsync(decoratedSupplier);

You can also decorate a CompletableFuture.

Supplier<CompletableFuture<String>> completableFutureSupplier =
    () -> CompletableFuture.supplyAsync(backendService.doSomething());

Supplier<CompletableFuture<String>> decoratedCompletableFutureSupplier =
    CircuitBreaker.decorateCompletionStage(circuitBreaker, completableFutureSupplier);

The advantage is that you can create them lazily and execute them at a later point in time.

We also provide a custom CircuitBreaker operator for Reactive Streams (RxJava).

But you are right. Bulk heading is not in the scope of this library.

[jhalterman]

@RobWin I like the decorator approach, especially since you can very explicitly compose an execution with a circuit breaker inside an execution with retries, or visa versa. I posted some thoughts on this, with respect to the currently proposed approach, here.

[RobWin]

Thx @jhalterman I have a look at it.

[Emily-Jiang]

@RobWin @jhalterman Are you talk about the difference between failsafe and javalang-circuitbreaker? @RobWin please elaborate your ideas via submitting a PR for any apis suggestions.

[jhalterman]

A Failsafe style API could certainly wrap callables in the same way that javaslang-circuitbreaker does:

Callable<Connection> connectWithRetries = executor.wrap(this::connect);

That would resolve the main discrepancy in terms of how they work (correct me if I'm wrong).

There is some dispute about whether wrapping callables at all is a good idea, since that can change the potential result or lead to unexpected exceptions. You can read a bit of that here.

[RobWin]

That would question the decorator pattern, higher order functions and function composition in general.

[Emily-Jiang]

@RobWin @jhalterman we are having hangout to discuss Fault Tolerance tomorrow. Please view the calendar here and try to join in.

[RobWin]

We renamed javaslang-circuitbreaker to resilience4j. See https://github.com/resilience4j/resilience4j

[Emily-Jiang]

@RobWin great! Thanks for letting me know! Can you view the apis/spis under the github to see whether you have any comments?