[jira] [Comment Edited] (CAMEL-24887) ManagedRouteGroupMBean exchange stats changed

["Torsten Mielke (Jira)" <ji...@apache.org>]

    [ 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)