CAMEL-19528: Replace CountDownLatch with Awaitility in camel-jpa tests#24411
Conversation
Replace flaky CountDownLatch-based synchronization with Awaitility polling in JPA consumer tests. The CountDownLatch pattern caused intermittent hangs and timeouts in CI because the JPA consumer's scheduled polling (1s initial delay, 500ms interval) could miss the fixed deadline under load. Changes: - JpaWithNamedQueryTest: replace CountDownLatch + latch.await() with Awaitility await().untilAsserted() - JpaTest: same CountDownLatch to Awaitility migration - JpaWithNamedQueryAndParametersTest: same migration - Re-enable JpaWithQueryTest, JpaWithNativeQueryTest, and JpaWithNativeQueryWithResultClassTest by removing @DisabledIfSystemProperty annotations (the underlying timing issue in their parent class is now fixed) - Mark receivedExchange fields as volatile for thread-safe publication Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 1 tested, 0 compile-only — current: 9 all testedMaveniverse Scalpel detected 1 affected modules (current approach: 9). Modules only in current approach (8)
Skip-tests mode would test 1 modules (1 direct + 0 downstream), skip tests for 0 (generated code, meta-modules) Modules Scalpel would test (1)
All tested modules (9 modules)
|
There was a problem hiding this comment.
Pull request overview
This PR improves the reliability of camel-jpa consumer tests by replacing timing-sensitive CountDownLatch synchronization with Awaitility-based polling and by re-enabling previously CI-disabled test classes now that the underlying flakiness is addressed.
Changes:
- Replaced
CountDownLatch-based waiting withawait().untilAsserted(...)in JPA consumer tests and madereceivedExchangevolatilefor cross-thread visibility. - Re-enabled CI-disabled test classes by removing
@DisabledIfSystemPropertyguards and standardizing on@Timeout(30). - Kept assertions resilient to scheduling jitter by retrying until conditions are met (within explicit time bounds).
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| components/camel-jpa/src/test/java/org/apache/camel/component/jpa/JpaWithQueryTest.java | Re-enables the test on CI by removing CI-specific disabling. |
| components/camel-jpa/src/test/java/org/apache/camel/component/jpa/JpaWithNativeQueryWithResultClassTest.java | Re-enables the test on CI and adds a class-level timeout. |
| components/camel-jpa/src/test/java/org/apache/camel/component/jpa/JpaWithNativeQueryTest.java | Re-enables the test on CI by removing CI-specific disabling. |
| components/camel-jpa/src/test/java/org/apache/camel/component/jpa/JpaWithNamedQueryTest.java | Replaces latch synchronization with Awaitility and makes receivedExchange volatile. |
| components/camel-jpa/src/test/java/org/apache/camel/component/jpa/JpaWithNamedQueryAndParametersTest.java | Replaces latch synchronization with Awaitility and makes receivedExchange volatile. |
| components/camel-jpa/src/test/java/org/apache/camel/component/jpa/JpaTest.java | Replaces latch synchronization with Awaitility and makes receivedExchange volatile. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Summary
CountDownLatch-based synchronization with Awaitilityawait().untilAsserted()in JPA consumer tests (JpaWithNamedQueryTest,JpaTest,JpaWithNamedQueryAndParametersTest)JpaWithQueryTest,JpaWithNativeQueryTest,JpaWithNativeQueryWithResultClassTest) by removing@DisabledIfSystemPropertyannotations — the underlying timing issue in their parent class is now fixedreceivedExchangefields asvolatilefor correct cross-thread visibilityRoot cause: The
CountDownLatch+latch.await(timeout)pattern in consumer tests was timing-sensitive. The JPA consumer uses scheduled polling (1s initial delay, 500ms interval), and under CI load the consumer poll could arrive after the fixed deadline, causing hangs or assertion failures. Awaitility's polling approach retries the assertion until it passes, making the tests resilient to scheduling jitter.Test plan
Thread.sleeporCountDownLatchremaining in modified test filesmvn formatter:format impsort:sortClaude Code on behalf of Guillaume Nodet
🤖 Generated with Claude Code