CircuitBreaker

[reactor]

CircuitBreaker

[akarnokd]

• L87: Sending the Subscription downstream is not recommended, looks like you wanted this.
• L101: not really necessary unless you want to be very eager.

[smaldini]

• The cancelled check onComplete/onError/onNext could/should be a separate non volatile boolean done.
• cancel() could be defensive against double cancellation by checking cancelled, in fact it could be an int volatile + AtomicFieldIntegerUpdater to compareAndSet.

[smaldini]

• I would also use a noop like Operators.error(Subscriber, Throwable) subscription for the onSubscribe error case
• the circuitBreaker should be notified of cancel or the circuit would be permanent in some cases (e.g. someone using take(5) just after the operator)

[smaldini]

• Eventually the circuit could collect health state from onNext and request events too (received a request at time T, received this amount of value or termination in T2).

[RobWin]

Thank you for your comments. I'm not sure if I understood all of them.

• L87 is fixed.
• I thought L101 helps to reduce the number of requests on the childSubscriber.

The cancelled check onComplete/onError/onNext could/should be a separate non volatile boolean done.

The boolean cancelled flags are already separated and volatile? Or do you mean something else?

I would also use a noop like Operators.error(Subscriber, Throwable) subscription for the onSubscribe error case

What do you mean by Operators.error(Subscriber, Throwable). Do you have an example?
RxJava does not seem to have that feature.

[RobWin]

the circuitBreaker should be notified of cancel or the circuit would be permanent in some cases (e.g. someone using take(5) just after the operator)

The CircuitBreaker is permanent which means that you should have one CircuitBreaker instance per backend system and reuse the instance to secure several streams.

[RobWin]

Eventually the circuit could collect health state from onNext and request events too (received a request at time T, received this amount of value or termination in T2).

The CircuitBreaker publishes a stream of events. If a call is successful, it publishes a CircuitBreakerOnSuccessEvent and if a call fails, it publishes a CircuitBreakerOnErrorEvent.
It also publishes events about state transitions. But I don't want to publish too many events which might not be interesting for monitoring systems.

The CircuitBreaker can only be used for cold streams and not for hot streams.

[smaldini]

Cold stream of scalar volume then or basically promise/mono/single/maybe/completable.
I'd think that in RS it might be interesting to monitor active subscriptions (and so cancelling should be bridged) and their throughput using request/item-received on fixed windows.

[RobWin]

Is the cancelled check onComplete/onError/onNext ok like this?

https://github.com/RobWin/javaslang-circuitbreaker/blob/master/src/main/java/io/github/robwin/circuitbreaker/operator/CircuitBreakerOperator.java#L75

https://github.com/RobWin/javaslang-circuitbreaker/blob/master/src/main/java/io/github/robwin/circuitbreaker/operator/CircuitBreakerOperator.java#L105

https://github.com/RobWin/javaslang-circuitbreaker/blob/master/src/main/java/io/github/robwin/circuitbreaker/operator/CircuitBreakerOperator.java#L138-L143

[gembin]

Any progress so far?

[RobWin]

@smaldini Is there any guide how to write custom Spring Reactor operators?
I tried to create a custom Reactor operator, but I failed.

[smaldini]

We folow he same guidelines as rxjava2 but we haven't done our own guide yet as we are pushing a bit more the API and toolkit until 3.1 now.
One thing tho, having at least a simplified version of such operator (if it was encapsulated as one FluxCircuitBreaker + java parameters vs custom contract) we would welcome it in core probably for Mono/Flux.

[leonard84]

@smaldini 3.1 is released, could we get it in now?

@RobWin I wanted to look at your attempt, but unfortunately the source code links are invalid now.

[RobWin]

@leonard84 We only have a RxJava addon. See: https://github.com/resilience4j/resilience4j/tree/master/resilience4j-rxjava2/src/main/java/io/github/resilience4j
We need help add support for Reactor.

[leonard84]

@RobWin I saw the rxjava2 implementation. You said

We need help add support for Reactor.

but without the prototype code for the reactor support it is hard to see/fix the problems.

[simonbasle]

@RobWin looks like this largely built on Publisher/Subscriber now, so the differences should not be that great, with limited adaptation effort.

[michael-barker]

@RobWin Any update on this? I'd love to be able to use Reslience4j with Reactor.

[RobWin]

I wont't have time to implement it, but we have RxJava2 operators which have been reviewed by @akarnokd.
If would be awesome if someone would like to contribute Reactor operators.

[michael-barker]

I'd be willing to give it a shot but not sure I'm well versed enough in Resilience4j and Reactor.

[RobWin]

Nice. I can invite you into our slack channel if you have questions regarding Resilience4j.

[leonard84]

@RobWin isn't this issue redundant, as https://github.com/resilience4j/resilience4j now has a reactor module?