Uploaded image for project: 'Red Hat build of Apache Camel for Spring Boot'
  1. Red Hat build of Apache Camel for Spring Boot
  2. CSB-7265

camel-resilience4j-starter record/ignore exception should handle wrapped exceptions

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Normal Normal
    • CSB-4.10.6
    • CSB-4.10.3
    • Camel
    • False
    • Hide

      None

      Show
      None
    • False
    • Very Likely
    • 0

      Even when an Exception which is not listed on the "recordException" option is thrown, the circuit break also counts it as failure.
      Modified camel-spring-boot-examples/resilience4j/client/src/main/java/sample/camel/ClientRoute.java

          @Override
          public void configure() {
      
              from("timer:trigger?period=1000").streamCaching()
                  .bean("counterBean")
                  .log(" Client request: ${body}")
                  .circuitBreaker()
                   .resilience4jConfiguration()
                       .recordException(new NullPointerException()).end()
                      .to("{{service1.url}}")
                      .log("Client throw a fake NoSuchMethodException to trigger circuit breaker")
                      .throwException(new NoSuchMethodException("Fake exception to trigger circuit breaker"))
                  .onFallback()
                      .to("{{service2.url}}")
                  .end()
      

      [Log]

      2025-06-23T09:35:14.922+09:00  INFO 3780 --- [           main] sample.camel.ClientApplication           : Started ClientApplication in 0.547 seconds (process running for 0.641)
      2025-06-23T09:35:15.936+09:00  INFO 3780 --- [timer://trigger] route1                                   :  Client request: 1
      2025-06-23T09:35:16.004+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client throw a fake NoSuchMethodException
      2025-06-23T09:35:16.032+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client response: Service2-1
      2025-06-23T09:35:16.923+09:00  INFO 3780 --- [timer://trigger] route1                                   :  Client request: 2
      2025-06-23T09:35:16.928+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client throw a fake NoSuchMethodException
      2025-06-23T09:35:16.931+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client response: Service2-2
      2025-06-23T09:35:17.925+09:00  INFO 3780 --- [timer://trigger] route1                                   :  Client request: 3
      2025-06-23T09:35:17.935+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client throw a fake NoSuchMethodException
      2025-06-23T09:35:17.939+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client response: Service2-3
      2025-06-23T09:35:18.926+09:00  INFO 3780 --- [timer://trigger] route1                                   :  Client request: 4
      2025-06-23T09:35:18.933+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client throw a fake NoSuchMethodException
      2025-06-23T09:35:18.937+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client response: Service2-4
      2025-06-23T09:35:19.931+09:00  INFO 3780 --- [timer://trigger] route1                                   :  Client request: 5
      2025-06-23T09:35:19.939+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client throw a fake NoSuchMethodException
      2025-06-23T09:35:19.948+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client response: Service2-5
      2025-06-23T09:35:20.936+09:00  INFO 3780 --- [timer://trigger] route1                                   :  Client request: 6
      2025-06-23T09:35:20.944+09:00  INFO 3780 --- [timer://trigger] route1                                   : Client response: Service2-6
      

      The Resilience4j's community document describes it's behavior as follows:
      https://resilience4j.readme.io/docs/circuitbreaker

      Failure rate and slow call rate thresholds
      
      The state of the CircuitBreaker changes from CLOSED to OPEN when the failure rate is equal or greater than a configurable threshold. For example when more than 50% of the recorded calls have failed.
      By default all exceptions count as a failure. You can define a list of exceptions which should count as a failure. All other exceptions are then counted as a success, unless they are ignored. Exceptions can also be ignored so that they neither count as a failure or success.
      

              cmiranda@redhat.com Claudio Miranda
              rhn-support-hfuruich Hisao Furuichi
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: