[ 
https://issues.apache.org/jira/browse/CAMEL-24818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-24818:
-----------------------------------

    Assignee: Claus Ibsen

> 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
>
> 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)

Reply via email to