You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Guillaume Nodet (Jira)" <ji...@apache.org> on 2026/07/27 12:02:00 UTC
[jira] [Created] (CAMEL-24265) DefaultTracer.traceCounter should use AtomicLong instead of plain long
Guillaume Nodet created CAMEL-24265:
---------------------------------------
Summary: DefaultTracer.traceCounter should use AtomicLong instead of plain long
Key: CAMEL-24265
URL: https://issues.apache.org/jira/browse/CAMEL-24265
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Guillaume Nodet
Found during review of PR #24985 (CAMEL-24227: volatile sweep for JMX-writable fields).
This is the reverse direction from CAMEL-24227 — routing threads *write* traceCounter++ while JMX *reads* it via ManagedTracer.getTraceCounter() / resetTraceCounter().
h3. Problem
{{DefaultTracer.traceCounter}} is a plain {{long}} that is:
* *Incremented* non-atomically ({{traceCounter++}}) on routing threads in the tracing hot path
* *Read and reset* via JMX through {{ManagedTracer}}
This has two JMM issues:
# *Visibility* — JMX reads may see stale values
# *Atomicity* — {{++}} is a non-atomic read-modify-write; on 32-bit JVMs even the read of a {{long}} is non-atomic (JLS 17.7)
{{BacklogTracer}} already uses {{AtomicLong}} for the same purpose — {{DefaultTracer}} should be aligned.
h3. Suggested fix
Replace {{private long traceCounter}} with {{private final AtomicLong traceCounter = new AtomicLong()}} and update {{getTraceCounter()}} / {{resetTraceCounter()}} accordingly.
h3. References
* PR [#24985|https://github.com/apache/camel/pull/24985] review comment by oscerd
* {{core/camel-base-engine/src/main/java/org/apache/camel/impl/engine/DefaultTracer.java}} line 62
--
This message was sent by Atlassian Jira
(v8.20.10#820010)