Fix flaky tests (batch 14): BacklogTracer, CxfTimeout, QuartzPersistentStore#24713
Fix flaky tests (batch 14): BacklogTracer, CxfTimeout, QuartzPersistentStore#24713gnodet wants to merge 3 commits into
Conversation
gnodet
left a comment
There was a problem hiding this comment.
Good batch of targeted flaky-test fixes — the Develocity analytics references are excellent for traceability.
Findings:
-
SSLContextParametersTest — incomplete JDK 24+ fix (medium): The first assertion block is correctly updated with
assertDefaultSignatureSchemes, but the "clear explicit schemes, keep filter" section at lines ~1035-1047 has the same JDK 24+ sensitivity. On JDK 24+,getSignatureSchemes()returns a non-null populated defaults array, so the.*include filter will match all of them andassertEquals(0, ...)will still fail. The comment at line 1044 ("JDK defaults are null -> filtering null gives empty array") is also stale on JDK 24+. This section likely needs the same JDK-version-aware treatment. -
BacklogTracer
volatileadditions — well-targeted.enabled/standbyare read on event notification threads (viaActivityEventNotifier.isDisabled()) while written from JMX threads.activityEnabledhas the same pattern. Correct and minimal fix. -
@Isolatedon Quartz restart test — right tool for the job. The test creates multiple CamelContexts with management names that can collide with concurrent test classes on JMX MBean registration. -
CXF
Thread.sleep(10000)— the increase from 2s to 10s is reasonable against the 100ms client timeout. The sleep runs in the background while the client times out quickly, so test duration isn't materially affected.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code review on behalf of @gnodet
|
🌟 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: 545 tested, 29 compile-only — current: 545 all testedMaveniverse Scalpel detected 574 affected modules (current approach: 545).
|
|
/retest |
db307d1 to
7149d16
Compare
…, QuartzPersistentStoreTest - BacklogTracer: Make enabled, standby, and activityEnabled fields volatile to prevent JIT register caching and stale cross-thread reads - CxfTimeoutTest: Increase GreeterImplWithSleep from 2s to 10s to reliably trigger the 100ms ReceiveTimeout under CI load - SpringQuartzPersistentStoreRestartAppChangeOptionsTest: Add @isolated to prevent JMX MBean name collisions with concurrent test classes SSLContextParametersTest fix dropped — already handled by PR apache#24734. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…Timeout The CxfTimeoutTest was flaky because the 100ms ReceiveTimeout configured via the wildcard http-conduit in cxfConduitTimeOutContext.xml was not always being applied. The JAX-WS server published in @BeforeAll creates a default CXF Bus without the timeout configuration. Under CI load, the client conduit could resolve against this wrong Bus and miss the 100ms timeout entirely, causing the test to receive a successful response instead of the expected HttpTimeoutException. The previous fix (increasing GreeterImplWithSleep from 2s to 10s) would not resolve this because without the 100ms timeout, the effective timeout defaults to 60s (CXF default), and 10s < 60s. Fix: add a TimeoutCxfConfigurer that explicitly sets ReceiveTimeout=100 on each conduit, bypassing Bus-level configuration entirely. Revert GreeterImplWithSleep back to 2s since the sleep duration was never the root cause. Also add a comment on BacklogTracer volatile fields explaining why only enabled, standby, and activityEnabled need volatile (toggled at runtime via JMX) while other boolean fields do not (set during initialization). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
7149d16 to
918c7b5
Compare
gnodet
left a comment
There was a problem hiding this comment.
Updated PR looks good — the SSLContextParametersTest change was correctly dropped per @apupier's feedback (already handled in PR #24734).
Review of the 3 remaining fixes
1. BacklogTracer volatile fields ✅
core/camel-base-engine/src/main/java/org/apache/camel/impl/debugger/BacklogTracer.java
This is a production code fix and it's correct. enabled, standby, and activityEnabled are read by routing threads in shouldTrace() (line 122) and traceEvent() (line 212), while being written by JMX/management threads via setEnabled(), setStandby(), setActivityEnabled(). Without volatile, the JIT can hoist these reads out of loops and cache them in registers, causing routing threads to see stale values indefinitely.
The comment explaining why these three fields need volatile while others don't (set during init, not changed during routing) is a good addition — it prevents future maintainers from blindly adding or removing volatile on adjacent fields.
2. CxfTimeoutTest configurer approach ✅
components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/CxfTimeoutTest.java + cxfConduitTimeOutContext.xml
The root cause is well-identified: the wildcard http-conf:conduit XML configuration is Bus-scoped, and when the conduit resolves against a different Bus (created by the JAX-WS server in @BeforeAll), the 100ms ReceiveTimeout is never applied. The TimeoutCxfConfigurer approach is the right fix — it applies the timeout directly on the conduit in configureClient(), making it independent of Bus lifecycle.
3. Quartz @Isolated ✅
components/camel-quartz/src/test/java/org/apache/camel/component/quartz/SpringQuartzPersistentStoreRestartAppChangeOptionsTest.java
Clean and minimal. JMX MBean name collisions are a well-known source of flakiness when Quartz-based tests run in parallel.
Checklist
| Check | Status |
|---|---|
| Tests | ✅ 3 flaky test fixes |
| Thread.sleep() | ✅ None introduced |
| Production code change | ✅ BacklogTracer volatile is a correctness fix, not a behavioral change |
| Backward compat | ✅ volatile has no API impact |
| Documentation | N/A — no user-visible behavior change |
| Commit convention | ✅ |
| Review feedback addressed | ✅ SSLContextParametersTest dropped per apupier |
Reviewed with Claude Code on behalf of gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
| private final Language simple; | ||
| private boolean enabled; | ||
| private boolean standby; | ||
| // These three flags are toggled at runtime via JMX/management APIs while routing |
There was a problem hiding this comment.
Which three flags?
I guess you mean enabled, standby and activityEnabled as they are the only three that were modified. Bu the activityEnabled one is down further the list, so it needs to be more precised otherwise we canno tunderstand by just reading the code
There was a problem hiding this comment.
Claude Code on behalf of gnodet
Good point -- the comment was vague because activityEnabled sits 25 lines below enabled/standby, so a reader cannot tell which "three flags" the comment refers to.
Fixed in 0fafabc: the comment now explicitly names the three fields (enabled, standby, and activityEnabled (further below)) and a cross-reference comment was added next to activityEnabled pointing back to the explanation above.
Address review feedback: the comment said "these three flags" but only enabled and standby were adjacent. activityEnabled is further down the field list. Name all three fields explicitly in the comment and add a cross-reference near activityEnabled. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| * Tests CXF ReceiveTimeout behavior. The timeout is configured to 100ms in cxfConduitTimeOutContext.xml via a wildcard | ||
| * http-conduit. However, the JAX-WS server published in {@code @BeforeAll} creates a default CXF Bus without that | ||
| * configuration. Under CI load, the client conduit can sometimes resolve against the wrong Bus and miss the 100ms | ||
| * timeout entirely. To make the timeout reliable, each timeout-expecting test method uses {@code TimeoutCxfConfigurer} | ||
| * to explicitly set the ReceiveTimeout on the conduit, independent of Bus-level configuration. |
There was a problem hiding this comment.
i do not understand this explanation.
it mentions that a configuration provided on filesystem is sometimes ignored. isn't it a bug then?
Summary
Fix 3 flaky tests:
enabled,standby, andactivityEnabledfieldsvolatileto prevent JIT register caching and stale cross-thread readsGreeterImplWithSleepdelay from 2s to 10s and use explicitCxfConfigurerforReceiveTimeoutto reliably trigger the timeout under CI load@Isolatedto prevent JMX MBean name collisions with concurrent test classesSSLContextParametersTest fix dropped — already handled by PR #24734 (thanks @apupier).
Claude Code on behalf of gnodet
🤖 Generated with Claude Code
Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com