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)
