[
https://issues.apache.org/jira/browse/CAMEL-24887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124385#comment-18124385
]
Torsten Mielke edited comment on CAMEL-24887 at 10/7/26 9:54 AM:
-----------------------------------------------------------------
_Analysis by Claude Code on behalf of tmielke_
h3. Summary of analysis
The behavior change in {{getExchangesCompleted()}} is a side-effect of the
CAMEL-24590 fix (merged in 4.22.1). Before that fix,
{{JmxManagementLifecycleStrategy}} created a separate {{ManagedRouteGroup}}
instance for each route in the group, but only the first one was registered as
the JMX MBean. As a result, the MBean only saw events from a single route —
accidentally showing a count of 1 per message. The CAMEL-24590 fix correctly
shares one {{ManagedRouteGroup}} instance across all routes in the group, so
the counter now reflects the sum of all route-level completions (e.g., 2 when
one message traverses two routes in the group).
The current behavior is correct: the CAMEL-24590 fix should not be reverted.
However, the request for an additional "per-transaction" metric (counting
unique messages rather than route-level events) is a valid enhancement. I'd
suggest reclassifying this ticket from Bug to Improvement.
h3. Workaround
The per-transaction count is already available through the individual route
MBeans. By querying {{ExchangesCompleted}} on the specific
{{ManagedRouteMBean}} for the entry route of the group (the first route that
receives the message), you get the count of unique messages entering the group.
This can be accessed via JMX under {{type=routes}} or programmatically through
{{{}ManagedCamelContext.getManagedRoute(routeId){}}}.
h3. Challenges of the requested feature
Implementing a deduplicated "transaction count" alongside the existing
aggregate count raises several design questions:
* Deduplication mechanism: The most practical approach is to mark each
exchange with a property (e.g., {{{}CamelRouteGroupCompleted_<group>{}}}) on
first processing, and only increment the transaction counter when the property
is absent. This avoids memory leaks since the property lives on the exchange
itself.
* Ambiguous outcome: If an exchange completes successfully in one group route
but fails in another, should the transaction be counted as completed, failed,
or both? The "first callback wins" approach may produce surprising results.
* Scope of new metrics: The same aggregate-vs-transaction question applies to
all performance counters (processing times, failures handled, redeliveries),
not just exchange counts. A decision is needed on whether to add
transaction-level equivalents for all counters or just for exchange counts.
* Exchange property overhead: Adding a property per group per exchange is low
overhead, but adds to the exchange's property map for every exchange flowing
through a grouped route.
h3. Decisions needed before implementation
# Naming convention — What should the new methods be called? Options include
{{getGroupExchangesCompleted()}} (deduplicated) vs keeping
g{{{}etExchangesCompleted(){}}} (aggregate), or {{getTransactionsCompleted()}}
vs {{{}getAggregatedExchangesCompleted(){}}}. Note that "transaction" has an
existing meaning in Camel (JTA transactions), so it may cause confusion.
# Scope — Should new transaction-level methods cover only exchange counts
(completed, failed, total), or also processing times and failure-handling
counters?
# Edge-case semantics — How should a transaction that completes in one route
and fails in another within the same group be classified at the transaction
level?
was (Author: tmielke):
_Analysis by Claude Code on behalf of tmielke_
h3. Summary of analysis
The behavior change in {{getExchangesCompleted()}} is a side-effect of the
CAMEL-24590 fix (merged in 4.22.1). Before that fix,
{{JmxManagementLifecycleStrategy}} created a separate {{ManagedRouteGroup}}
instance for each route in the group, but only the first one was registered as
the JMX MBean. As a result, the MBean only saw events from a single route —
accidentally showing a count of 1 per message. The CAMEL-24590 fix correctly
shares one {{ManagedRouteGroup}} instance across all routes in the group, so
the counter now reflects the sum of all route-level completions (e.g., 2 when
one message traverses two routes in the group).
The current behavior is correct: the CAMEL-24590 fix should not be reverted.
However, the request for an additional "per-transaction" metric (counting
unique messages rather than route-level events) is a valid enhancement. I'd
suggest reclassifying this ticket from Bug to Improvement.
h3. Workaround
The per-transaction count is already available through the individual route
MBeans. By querying {{ExchangesCompleted}} on the specific
{{ManagedRouteMBean}} for the entry route of the group (the first route that
receives the message), you get the count of unique messages entering the group.
This can be accessed via JMX under {{type=routes}} or programmatically through
{{{}ManagedCamelContext.getManagedRoute(routeId){}}}.
Challenges of the requested feature
Implementing a deduplicated "transaction count" alongside the existing
aggregate count raises several design questions:
* Deduplication mechanism: The most practical approach is to mark each
exchange with a property (e.g., {{{}CamelRouteGroupCompleted_<group>{}}}) on
first processing, and only increment the transaction counter when the property
is absent. This avoids memory leaks since the property lives on the exchange
itself.
* Ambiguous outcome: If an exchange completes successfully in one group route
but fails in another, should the transaction be counted as completed, failed,
or both? The "first callback wins" approach may produce surprising results.
* Scope of new metrics: The same aggregate-vs-transaction question applies to
all performance counters (processing times, failures handled, redeliveries),
not just exchange counts. A decision is needed on whether to add
transaction-level equivalents for all counters or just for exchange counts.
* Exchange property overhead: Adding a property per group per exchange is low
overhead, but adds to the exchange's property map for every exchange flowing
through a grouped route.
h3. Decisions needed before implementation
# Naming convention — What should the new methods be called? Options include
{{getGroupExchangesCompleted()}} (deduplicated) vs keeping
g{{{}etExchangesCompleted(){}}} (aggregate), or {{getTransactionsCompleted()}}
vs {{{}getAggregatedExchangesCompleted(){}}}. Note that "transaction" has an
existing meaning in Camel (JTA transactions), so it may cause confusion.
# Scope — Should new transaction-level methods cover only exchange counts
(completed, failed, total), or also processing times and failure-handling
counters?
# Edge-case semantics — How should a transaction that completes in one route
and fails in another within the same group be classified at the transaction
level?
> ManagedRouteGroupMBean exchange stats changed
> ---------------------------------------------
>
> Key: CAMEL-24887
> URL: https://issues.apache.org/jira/browse/CAMEL-24887
> Project: Camel
> Issue Type: Improvement
> Components: camel-jmx
> Affects Versions: 4.22.1
> Reporter: Raymond
> Assignee: Torsten Mielke
> Priority: Minor
>
> In 4.22.1 the exchange stats in the {{ManagedRouteGroupMBean}} changed.
> As an example I have created a route group X with two routes X1 and X2. Now I
> would like to get how many "transactions" the group processed. I used:
> {{ManagedRouteGroupMBean managedRouteGroup =
> managedContext.getManagedRouteGroup("X");}}
> {{managedRouteGroup.getExchangesCompleted()}}
> Now when I processed 1 message/transaction I would like to get the number 1,
> etc. This worked until 4.22.0, but this recently changed.
> In 4.22.0 the result was 1
> In 4.22.1 the result is 2
> The second is the aggregated processed exchanges of all routes in the group.
> This is useful too, but I would still like to have the old result. This can
> be in a separated method:
> {{managedRouteGroup.getExchangesCompleted() --> 1}}
> {{managedRouteGroup.getAggegatedExchangesCompleted() --> 2}}
> or
> {{managedRouteGroup.getTransactionsCompleted() --> 1}}
> {{managedRouteGroup.getExchangesCompleted() --> 2}}
> This may have changed after this issue:
> https://issues.apache.org/jira/browse/CAMEL-24590
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
