[
https://issues.apache.org/jira/browse/CAMEL-24818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-24818.
---------------------------------
Resolution: Fixed
> 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: camel-microprofile-fault-tolerance, eip
> Reporter: Claus Ibsen
> Assignee: Claus Ibsen
> Priority: Minor
> Fix For: 4.23.0
>
>
> 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)