tmielke commented on PR #27576:
URL: https://github.com/apache/camel/pull/27576#issuecomment-6062529993
Responding to @davsclaus's wireTap comment and @Croway's handled-failure
concern:
Thank you both for the thorough reviews. I investigated the wireTap
behavior in detail by adding stack trace tracing to
DefaultUnitOfWork.pushRoute(), and the results show that the
copy's routeStackLevel is 2, not 1. Here's what actually happens:
Why the wireTap copy has routeStackLevel=2:
1. createCorrelatedCopy(exchange, false) sets copy.setUnitOfWork(null) —
correct so far.
2. WireTapTask.run() calls asyncProcessor.process(copy). This
asyncProcessor is a CamelInternalProcessor belonging to the source route
("wt"). Its
UnitOfWorkProcessorAdvice.before() creates a new UoW and pushes "wt"
onto the stack. Stack level = 1.
3. Inside that CIP's processor chain, a SendProcessor sends the copy to
direct:wt-target. The DirectProducer enters another CamelInternalProcessor —
this one for route "wt-target".
Its UnitOfWorkProcessorAdvice.before() sees the UoW already exists and
pushes "wt-target". Stack level = 2.
4. When completedExchange fires for "wt-target", both the
ManagedCamelContext dedup (routeStackLevel <= 1 → false) and the
ManagedRouteGroup dedup (routeStackLevel <= 1 → false)
reject the copy.
The key detail is step 2: the WireTap wraps its target processor in a
CamelInternalProcessor from the source route (for error handling and UoW
management). This pushes the source
route onto the copy's UoW before the copy ever reaches the target route.
Both MCC and MRG are consistent:
I verified this with tracing output:
```
MCC.completedExchange: exchangeId=...0000 routeStackLevel=1 route=wt
counting=true
MCC.completedExchange: exchangeId=...0001 routeStackLevel=2
route=wt-target counting=false
MRG.completedExchange: group=g exchangeId=...0000 outermost=true
MRG.completedExchange: group=g exchangeId=...0001 outermost=false
```
Both ManagedCamelContext and ManagedRouteGroup count 1, not 2. The test
now asserts this consistency: assertEquals(ctxCompleted,
group.getExchangesCompleted()).
Regarding @Croway's handled-failure concern (P2):
I reproduced the scenario with the suggested test patch and extended it to
also check ManagedCamelContext.getFailuresHandled(). The result:
```
MCC failuresHandled=0
MRG failuresHandled=0
```
Both MCC and MRG report 0 for the wireTap copy's handled failure. The
route-level counter sees failuresHandled=1, but neither the context nor the
group counter counts it — because
the copy has routeStackLevel=2 and both use the <= 1 guard. This is a
pre-existing limitation of the routeStackLevel dedup approach that
ManagedCamelContext has used since
CAMEL-18557, not a regression introduced by this PR. Our fix applies the
same pattern to ManagedRouteGroup, inheriting the same limitation.
The comparison to "the PR's parent" passing the test is expected — before
this fix, ManagedRouteGroup had no dedup at all and counted every route event
unconditionally. That's
exactly the double-counting regression this PR fixes.
Regarding @Croway's doc concern (point 2):
Already addressed — the wording now says "once per entry into the group:
calls nested inside another route of the same group are not counted again",
with examples covering both
nested and sequential entry.
Summary:
If we want wireTap copies counted as separate exchanges (making the total
2), that would require changing how WireTapProcessor wires its inner
CamelInternalProcessor, or changing
the dedup logic in both ManagedCamelContext and ManagedRouteGroup. That's
a broader change beyond the scope of CAMEL-24887 and could be tracked as a
separate issue.
Claude Code on behalf of Torsten Mielke
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
