Claus Ibsen created CAMEL-24818:
-----------------------------------
Summary: circuitBreaker: set CamelCircuitBreakerResponseRejected
when the fallback runs because the breaker is open
Key: CAMEL-24818
URL: https://issues.apache.org/jira/browse/CAMEL-24818
Project: Camel
Issue Type: Improvement
Components: eip, camel-microprofile-fault-tolerance
Reporter: Claus Ibsen
When a circuitBreaker has an onFallback, the fallback path in
ResilienceProcessor and FaultToleranceProcessor sets the same exchange
properties for every cause: CamelCircuitBreakerResponseFromFallback=true and
CamelCircuitBreakerResponseShortCircuited=true, plus
CamelCircuitBreakerResponseTimedOut for a timeout.
CamelCircuitBreakerResponseRejected is only set when there is *no* fallback.
So inside an onFallback there is no way to tell whether the call was made and
failed (breaker closed or half open) or whether the call was never attempted
because the breaker is open (Resilience4j CallNotPermittedException, fault
tolerance CircuitBreakerOpenException), other than inspecting the exception
class. CamelCircuitBreakerState does not help either: it is read after the
failure is recorded, so the call that trips the breaker reports OPEN although
the call was made.
Proposal:
# In the fallback path of both processors set
CamelCircuitBreakerResponseRejected=true when the throwable is
CallNotPermittedException / BulkheadFullException (Resilience4j) or
CircuitBreakerOpenException / BulkheadException (fault tolerance), false
otherwise.
# Keep CamelCircuitBreakerResponseShortCircuited as is for compatibility, but
correct its description: it means the fallback handled the exchange, not that
the breaker skipped the call.
# Document the properties on the circuitBreaker EIP page.
A fallback can then answer differently for one failed call versus a dead
service, e.g. "breaker open, supplier not called" in the circuit-breaker
example of camel-jbang-examples (CAMEL-24808).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
