gnodet-bot commented on code in PR #26603:
URL: https://github.com/apache/camel/pull/26603#discussion_r4049307825


##########
components/camel-microprofile/camel-microprofile-fault-tolerance/src/test/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceCallCountersTest.java:
##########
@@ -0,0 +1,126 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.camel.component.microprofile.faulttolerance;
+
+import org.apache.camel.RoutesBuilder;
+import org.apache.camel.builder.RouteBuilder;
+import org.apache.camel.component.mock.MockEndpoint;
+import org.apache.camel.test.junit6.CamelTestSupport;
+import org.junit.jupiter.api.Test;
+
+import static org.junit.jupiter.api.Assertions.assertEquals;
+
+/**
+ * The fallback, timed out and bulkhead rejected counters, which the circuit 
breaker listeners do not tell apart.
+ */
+public class FaultToleranceCallCountersTest extends CamelTestSupport {
+
+    @Test
+    public void testFallbackAndRejectedCounters() throws Exception {
+        getMockEndpoint("mock:down").expectedMessageCount(3);
+
+        // two failures open the breaker, the third call is rejected without 
being attempted
+        template.sendBody("direct:down", "Hello World");
+        template.sendBody("direct:down", "Hello World");
+        template.sendBody("direct:down", "Hello World");
+
+        MockEndpoint.assertIsSatisfied(context);
+
+        FaultToleranceProcessor cb = context.getProcessor("cbDown", 
FaultToleranceProcessor.class);
+        assertEquals(3, cb.getNumberOfFallbackCalls());
+        assertEquals(1, cb.getNumberOfNotPermittedCalls());
+        assertEquals(0, cb.getNumberOfTimedOutCalls());
+        assertEquals(0, cb.getNumberOfBulkheadRejectedCalls());
+
+        cb.transitionToCloseState();
+        assertEquals(0, cb.getNumberOfFallbackCalls());
+    }
+
+    @Test
+    public void testTimedOutCounter() throws Exception {
+        getMockEndpoint("mock:slow").expectedBodiesReceived("Fallback 
response");
+
+        template.sendBody("direct:slow", "Hello World");
+
+        MockEndpoint.assertIsSatisfied(context);
+
+        FaultToleranceProcessor cb = context.getProcessor("cbSlow", 
FaultToleranceProcessor.class);
+        assertEquals(1, cb.getNumberOfFallbackCalls());
+        assertEquals(1, cb.getNumberOfTimedOutCalls());
+        assertEquals(0, cb.getNumberOfNotPermittedCalls());
+    }
+
+    @Test
+    public void testBulkheadRejectedWithFallbackCounter() throws Exception {
+        getMockEndpoint("mock:bulkhead").expectedMessageCount(2);
+
+        // the first call holds the only bulkhead permit while it is slow,
+        // so the second call is rejected by the bulkhead and answered by the 
fallback
+        template.asyncSendBody("direct:bulkhead", "Hello World");
+        Thread.sleep(500);
+        template.sendBody("direct:bulkhead", "Hello World");
+
+        MockEndpoint.assertIsSatisfied(context);
+
+        FaultToleranceProcessor cb = context.getProcessor("cbBulkhead", 
FaultToleranceProcessor.class);
+        assertEquals(1, cb.getNumberOfBulkheadRejectedCalls(),
+                "the rejected call is counted from inside the fallback path");
+        assertEquals(1, cb.getNumberOfFallbackCalls());
+        assertEquals(0, cb.getNumberOfNotPermittedCalls());
+        assertEquals(0, cb.getNumberOfTimedOutCalls());
+    }
+
+    @Override
+    protected RoutesBuilder createRouteBuilder() {
+        return new RouteBuilder() {

Review Comment:
   ⚠️ **`Thread.sleep(500)` is a timing assumption, not a synchronisation 
guarantee.**
   
   The test assumes the first `asyncSendBody` will have acquired the bulkhead 
permit within 500 ms. The slow service takes 2 s to respond, so the window is 
comfortable on developer hardware — but on a heavily loaded CI worker where 
thread scheduling can be delayed by several seconds, the second call may arrive 
before the first one holds the permit, making both calls succeed and the 
assertion `assertEquals(1, cb.getNumberOfBulkheadRejectedCalls())` fail 
non-deterministically.
   
   Use a latch to synchronise on permit acquisition instead:
   
   ```java
   CountDownLatch permitAcquired = new CountDownLatch(1);
   // in the route: .process(e -> 
permitAcquired.countDown()).to("direct:slowService")
   template.asyncSendBody("direct:bulkhead", "Hello World");
   permitAcquired.await(5, TimeUnit.SECONDS);
   template.sendBody("direct:bulkhead", "Hello World");
   ```
   
   Same issue exists in 
`ResilienceCallCountersTest.testBulkheadRejectedWithFallbackCounter` — both 
should be fixed.



##########
components/camel-resilience4j/src/main/java/org/apache/camel/component/resilience4j/ResilienceProcessor.java:
##########
@@ -409,11 +429,14 @@ public String getCircuitBreakerState() {
         }
     }
 
-    @ManagedOperation(description = "Transitions the circuit breaker to CLOSED 
state.")
+    @ManagedOperation(description = "Transitions the circuit breaker to CLOSED 
state and resets the fallback, timed out and bulkhead rejected call counters.")

Review Comment:
   ⚠️ **Counter reset gap: `transitionToOpenState()` and 
`transitionToHalfOpenState()` don't reset the new counters.**
   
   `transitionToCloseState()` now resets `fallbackCalls`, `timedOutCalls`, and 
`bulkheadRejectedCalls` (lines 430-432). The other two manual transition 
operations don't, so forcing the breaker OPEN or HALF_OPEN via JMX leaves stale 
counter values from the previous cycle — a user looking at the JMX attributes 
after `transitionToOpenState()` will see counters that no longer reflect the 
current state.
   
   `FaultToleranceProcessor` has no equivalent `transitionToOpenState`, so this 
is specific to `ResilienceProcessor`. Fix:
   
   ```suggestion
           fallbackCalls.set(0);
           timedOutCalls.set(0);
           bulkheadRejectedCalls.set(0);
       }
   
       @ManagedOperation(description = "Transitions the circuit breaker to OPEN 
state.")
       public void transitionToOpenState() {
           if (circuitBreaker != null) {
               circuitBreaker.transitionToOpenState();
           }
           fallbackCalls.set(0);
           timedOutCalls.set(0);
           bulkheadRejectedCalls.set(0);
   ```
   
   (Same reset block needed in `transitionToHalfOpenState()` and 
`transitionToForcedOpenState()`.)



##########
dsl/camel-jbang/camel-jbang-core/src/test/java/org/apache/camel/dsl/jbang/core/commands/process/ListCircuitBreakerTest.java:
##########
@@ -78,6 +78,9 @@ void testShowsClosedCircuitBreaker() throws Exception {
             String output = printer.getOutput();
             assertTrue(output.contains("myCB"), "Should show circuit breaker 
ID");
             assertTrue(output.contains("CLOSED"), "Should show CLOSED state");
+            assertTrue(output.contains("FALLBACK"), "Should show FALLBACK 
column");
+            assertTrue(output.contains("TIMEOUT"), "Should show TIMEOUT 
column");

Review Comment:
   Nit: use `assertFalse` instead of `assertTrue(!...)`.
   
   ```suggestion
               assertFalse(output.contains("BULKHEAD"), "Should not show 
BULKHEAD column without a bulkhead");
   ```
   
   `assertFalse` produces a cleaner failure message and both `assertFalse` and 
`assertTrue` are already imported in this file.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to