[
https://issues.apache.org/jira/browse/CAMEL-24229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-24229:
--------------------------------
Issue Type: Test (was: Bug)
> Fix flaky BacklogTracerActivityTest (volatile) and QuartzPersistentStore
> (MBean collision)
> ------------------------------------------------------------------------------------------
>
> Key: CAMEL-24229
> URL: https://issues.apache.org/jira/browse/CAMEL-24229
> Project: Camel
> Issue Type: Test
> Components: camel-core, camel-quartz
> Reporter: Guillaume Nodet
> Priority: Minor
> Labels: flaky-test
>
> Fix two flaky tests by addressing their root causes:
> h3. BacklogTracerActivityTest
> *Root cause*: {{enabled}}, {{standby}}, and {{activityEnabled}} fields in
> {{BacklogTracer}} were not {{volatile}}. When these flags are toggled via JMX
> while routing threads read them, JIT register caching can cause stale
> cross-thread reads. The test enables {{activityEnabled}} via JMX and
> immediately sends exchanges — the routing thread may cache the old {{false}}
> value in a register and never see the update.
> *Fix*: Mark all three fields {{volatile}}.
> h3. SpringQuartzPersistentStoreRestartAppChangeOptionsTest
> *Root cause*: Multiple Spring XML config files used the same
> {{managementNamePattern="#name#"}}, producing identical JMX ObjectNames. When
> sequential CamelContexts share the same management name and one is still
> unregistering when the next starts, a {{VetoCamelContextStartException}} is
> thrown.
> *Fix*: Give each Spring XML file a unique {{managementNamePattern}} suffix
> ({{-cron1}}, {{-cron2}}, {{-opts1}}, {{-opts2}}) so JMX ObjectNames never
> collide.
> h3. Related
> * The BacklogTracer fix covers only the 3 guard fields that cause the flaky
> test. A broader audit (50+ non-volatile JMX-writable fields across 12 engine
> classes) is tracked in CAMEL-24227.
> * PR: https://github.com/apache/camel/pull/24713
--
This message was sent by Atlassian Jira
(v8.20.10#820010)