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)