shashank created CAMEL-26710:
--------------------------------
Summary: camel-core - Split EIP with a resume strategy hangs when
the watermark cannot be evaluated or stored
Key: CAMEL-26710
URL: https://issues.apache.org/jira/browse/CAMEL-26710
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: shashank
Assignee: shashank
When a split with {{resumeStrategy}} completes, {{Splitter}} stores the
watermark in the callback of the split, and only then calls the original
callback, with no try/finally. If the resume strategy fails in
{{updateLastOffset}}, {{persistWatermark}} rethrows, the original callback is
never called, and the reactive executor only logs "Error executing reactive
work ... This exception is ignored". The caller blocks forever in
{{DefaultAsyncProcessorAwaitManager.await}}, the exchange stays in flight, and
only stopping the CamelContext releases it (graceful shutdown times out). Every
later split on the route hangs the same way. With {{synchronous()}} the
exception reaches the caller instead.
This happens for example with {{SingleNodeKafkaResumeStrategy}} after a route
stop/start, as it keeps the producer it closed on stop (reported separately),
so {{updateLastOffset}} throws "Cannot perform operation after producer has
been closed". The {{ResumeStrategy}} SPI declares {{updateLastOffset}} with
{{throws Exception}}, so any strategy can do this.
A {{watermarkExpression}} that throws on an item (for example a property that
the item does not have) hangs the split the same way, as it is evaluated in the
callback of each item.
{code:java}
from("direct:start")
.split(body()).resumeStrategy(strategyWhoseUpdateLastOffsetThrows, "job")
.to("mock:split");
// template.asyncSend("direct:start", List.of("a", "b", "c")).get(5, SECONDS)
times out:
// all items reach mock:split, but the exchange never completes
{code}
CAMEL-26301 fixed the same pattern (an exception escaping an async callback,
caller hangs) in {{TokenizerProcessor}}.
Expected: the split completes with the exception set, so the error handler and
the caller see a normal failure, and the watermark is not updated, as when the
split is aborted. As the failed exchange can then be redelivered, the watermark
should also only be cached in memory after it is stored; otherwise the
redelivery skips every item and stores nothing.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
