[
https://issues.apache.org/jira/browse/CAMEL-24143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-24143:
-----------------------------------
Assignee: Claus Ibsen
> camel-core - Split & Aggregate EIP review follow-ups (medium findings)
> ----------------------------------------------------------------------
>
> Key: CAMEL-24143
> URL: https://issues.apache.org/jira/browse/CAMEL-24143
> Project: Camel
> Issue Type: Bug
> Components: camel-core, eip
> Affects Versions: 4.21.0, 4.22.0
> Reporter: Federico Mariani
> Assignee: Claus Ibsen
> Priority: Major
> Attachments: camel-split-aggregate-eip-review-2026-07.md
>
>
> Umbrella for the medium findings from a code review of the
> Split/Multicast/Aggregate EIP processors in {{camel-core-processor}} (July
> 2026). The high findings are tracked separately: CAMEL-24138 (nested-split
> failure swallow), CAMEL-24139 (watermark data loss on abort), CAMEL-24140
> (UseOriginal + shareUnitOfWork), CAMEL-24141 (recovery/interval task death),
> CAMEL-24142 (lost multicast timeout). Full review document attached.
> Items new in CAMEL-23264 (unreleased 4.22.0-SNAPSHOT — can be fixed before
> release):
> # *M1 — errorThreshold ratio wrong under parallelProcessing*
> ({{Splitter.java:557-563}}): {{ratio = failureCount / (index + 1)}} uses the
> completing item's _original index_ as denominator, not the number of items
> completed so far. With out-of-order parallel completion a 1%-failure run can
> abort at {{errorThreshold(0.5)}} (low-index item failing late), or badly
> under-count. Use a completed-items counter as denominator.
> # *M2 — non-failure stop conditions recorded as "failures"*
> ({{Splitter.java:543-570}}): with thresholds configured,
> {{shouldContinueOnFailure}} records a {{SplitResult.Failure}} for any
> {{continueProcessing=false}} condition — including exceptions already handled
> by the error handler ({{Failure(index, null)}}), {{rollbackOnly}}, and a
> deliberate {{.stop()}} (routeStop) in the child route, whose semantics are
> silently overridden to "continue".
> # *M3 — SplitResult.getSuccessCount() counts never-attempted items as
> successes after an abort* ({{SplitResult.java:63-67}}): {{totalItems}} counts
> prepared/drained items, so after an abort {{totalItems - failureCount}}
> includes unprocessed items; can even go negative combined with CAMEL-24138.
> # *M7 — unguarded Integer.parseInt of the stored watermark*
> ({{Splitter.java:316-318}}): a non-numeric value under the watermark key (key
> previously used with {{watermarkExpression}}, shared key, corrupted store)
> fails every exchange with a bare {{NumberFormatException}}.
> Longstanding:
> # *M4 — optimistic-lock async retry can leak the callback*
> ({{AggregateProcessor.java:404-410}}): retries scheduled on the
> optimistic-locking executor have no try/catch; an unexpected
> (non-OptimisticLocking) exception from {{doProcess}} on the retry thread
> escapes and the {{AsyncCallback}} is never invoked — the exchange hangs. The
> first attempt is guarded by {{process()}}'s try/catch, the retry path is not.
> # *M5 — Statistics.reset() does not reset completedByInterval*
> ({{AggregateProcessor.java:207-218}}).
> # *M6 — aggregateCompletionCounter NPE on null CamelAggregatedCompletedBy*
> ({{AggregateProcessor.java:924-952}}) — also feeds the recovery-task death in
> CAMEL-24141.
> Low findings (L1-L6: timeout strategy lookup ignoring per-exchange
> strategies, watermark late-completion NPE, LRU'd error handlers never stopped
> — a {{Map}} is not {{Iterable}} so {{ServiceHelper.stopService}} skips it,
> StringAggregationStrategy delimiter edge, forceCompletionOfAllGroups count,
> errorThreshold first-item-abort docs) are described in the attached review
> document.
> _Filed by Claude Code on behalf of Federico Mariani (fmariani)_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
