[
https://issues.apache.org/jira/browse/CAMEL-24265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned CAMEL-24265:
---------------------------------------
Assignee: Guillaume Nodet
> 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
> Assignee: Guillaume Nodet
> Priority: Major
> Labels: good-first-issue
>
> 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)
