[jira] [Created] (CAMEL-24142) camel-core - Multicast/Split timeout silently lost when it fires while a result is being aggregated (tryLock never retried)

["Federico Mariani (Jira)" <ji...@apache.org>]

Federico Mariani created CAMEL-24142:
----------------------------------------

             Summary: camel-core - Multicast/Split timeout silently lost when it fires while a result is being aggregated (tryLock never retried)
                 Key: CAMEL-24142
                 URL: https://issues.apache.org/jira/browse/CAMEL-24142
             Project: Camel
          Issue Type: Bug
          Components: camel-core, eip
    Affects Versions: 4.21.0
            Reporter: Federico Mariani


The Multicast/Split {{timeout}} task is scheduled *once* per multicast execution ({{MulticastProcessor.java:452-453}}), and {{MulticastTask.timeout()}} starts with {{lock.tryLock()}} ({{MulticastProcessor.java:507-509}}) — if the lock is not free at the instant the timeout fires, the method returns immediately and the timeout is *never rescheduled*.

The same lock is held by {{MulticastTask.aggregate()}} for the entire duration of each completion's aggregation ({{completion.poll()}} + {{doAggregate}}, which runs the user's {{AggregationStrategy}}), and briefly by {{AsyncCompletionService.complete/poll}}. So whenever the timeout fires while any sub-exchange result is being aggregated, the timeout is silently dropped. If a remaining branch/item never replies — the very situation {{timeout}} exists for — the EIP never completes and the exchange *hangs forever* despite the configured timeout.

The race window is proportional to (aggregation time × number of completions); a slow custom aggregation strategy widens it arbitrarily.

*Reproducer (attached, fails on main):* {{MulticastTimeoutLostDuringAggregationIssueTest}} makes the race deterministic — branch A completes immediately and its aggregation blocks for 2s (holding the task lock), the timeout (500ms) fires in that window and is lost, branch B stays blocked, and the exchange does not complete within 8s:

{noformat}
org.opentest4j.AssertionFailedError: Configured multicast timeout (500ms) was silently lost because it fired while the aggregation lock was held
{noformat}

Suggested fix direction: on failed {{tryLock}}, reschedule {{timeout()}} after a short delay; or use {{lock.lock()}} — the aggregate loop's hold time is bounded by the strategy invocation, and the timeout task runs on the dedicated unbounded aggregate executor so blocking is acceptable there.

_Filed by Claude Code on behalf of Federico Mariani (fmariani)_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)