orpiske commented on code in PR #24270:
URL: https://github.com/apache/camel/pull/24270#discussion_r3481319704
##########
core/camel-core/src/test/java/org/apache/camel/component/direct/DirectProducerBlockingTest.java:
##########
@@ -74,29 +74,32 @@ public void testProducerBlocksWithNoConsumers() throws
Exception {
@Test
public void testProducerBlocksResumeTest() throws Exception {
+ getMockEndpoint("mock:result").expectedMessageCount(1);
+
context.getRouteController().suspendRoute("foo");
- CountDownLatch producerReady = new CountDownLatch(1);
+ Thread mainThread = Thread.currentThread();
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.submit(new Runnable() {
@Override
public void run() {
try {
- // Wait for producer to start blocking
- assertTrue(producerReady.await(2, TimeUnit.SECONDS));
+ // Wait for the main thread to enter TIMED_WAITING state
+ // (blocked on condition in DirectComponent.getConsumer)
+ await().atMost(2, TimeUnit.SECONDS)
+ .pollInterval(10, TimeUnit.MILLISECONDS)
+ .until(() -> mainThread.getState() ==
Thread.State.TIMED_WAITING);
+
Review Comment:
Minor observation: `TIMED_WAITING` is a reliable proxy here (the producer
blocks on `consumersCondition.await()` in `DirectComponent.getConsumer`), but
it's a heuristic — in theory the main thread could transiently enter
`TIMED_WAITING` earlier in the call path before reaching `getConsumer()`. With
the 10ms poll interval this is extremely unlikely in practice, and it's
strictly better than the prior `CountDownLatch` race.
Just something to keep in mind for future maintainers if this test ever
becomes flaky again — the `Thread.State` check is a practical workaround, not a
contract.
--
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]
