[
https://issues.apache.org/jira/browse/CAMEL-23281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071964#comment-18071964
]
Federico Mariani commented on CAMEL-23281:
------------------------------------------
Ciao [~spampi1991] thanks for reporting it and the clear reproducer, it really
helped.
This issue was introduced by https://issues.apache.org/jira/browse/CAMEL-23030
, in particular, the when the exchange is both transacted and using
SynchronousExecutorService, scheduleQueue(task) is called.
In this scenario we are mixing a _SynchronousExecutor_, with the Reactive
_scheduleQueue(task)_, as you can see from the tdump you shared
_DefaultAsyncProcessorAwaitManager.await(:105)_, the CountDownLatch can only be
counted down by work scheduled on the reactive executor, but the reactive
executor is this same thread, which is now blocked in a single-thread deadlock.
{code:java}
"Camel (camel-1) thread #1 - file://data" #72 [30168] daemon prio=5 os_prio=0
cpu=296.88ms elapsed=85.68s tid=0x000001ad7e080f30 nid=30168 waiting on
condition [0x0000006bfdbfc000]
java.lang.Thread.State: WAITING (parking)
- parking to wait for <0x00000007ffd3e310> (a
java.util.concurrent.CountDownLatch$Sync)
at CountDownLatch.await()
at DefaultAsyncProcessorAwaitManager.await(:105) ← BLOCKED HERE
at DefaultAsyncProcessorAwaitManager.process(:83)
at RedeliveryErrorHandler.process(:178)
at CamelInternalProcessor.processTransacted(:428)
at Pipeline$PipelineTask.run(:101)
at DefaultReactiveExecutor$Worker.executeFromQueue(:240) ← drained
queued task
at DefaultAsyncProcessorAwaitManager.await(:94) ← outer await
at DefaultAsyncProcessorAwaitManager.process(:83)
at RedeliveryErrorHandler.process(:178)
at CamelInternalProcessor.processTransacted(:428)
...
at MulticastProcessor$MulticastTransactedTask.doRun(:708) ← split
processing
at DefaultReactiveExecutor$Worker.executeFromQueue(:240) ← drained
another queued task
at DefaultAsyncProcessorAwaitManager.await(:94) ← yet another
outer await
...
at TransactionErrorHandler.processByErrorHandler(:244)
...
at GenericFileConsumer.processExchange(:484) ← file
consumer entry point
{code}
I've opened PRs for main (4.19) and 4.18.x branches, the fix will be available
in 4.18.2
> [camel-core] split/aggregator stuck in tx
> -----------------------------------------
>
> Key: CAMEL-23281
> URL: https://issues.apache.org/jira/browse/CAMEL-23281
> Project: Camel
> Issue Type: Bug
> Components: came-core
> Affects Versions: 4.18.1
> Reporter: Francesco Spampinato
> Assignee: Federico Mariani
> Priority: Minor
> Fix For: 4.18.2, 4.19.0
>
> Attachments: image-2026-04-02-00-55-36-946.png,
> threaddump-1775398792709.tdump
>
>
> Hi,
> i've a simple integration scenario.
> A csv file is polled from file system, the file is splitted and divided in
> chunks of certain size.
> Every chunk is persisted in bulk mode into a database, after that the file is
> moved into a processed folder. The entire file processing must be in
> transaction.
> {code:java}
> from(file("data").move("done"))
> .transacted()
> .split(body().tokenize(CSV_NEW_LINE)).streaming().stopOnException()
> .choice()
> .when(exchangeProperty(SPLIT_INDEX).isGreaterThan(0))
> .unmarshal().bindy(BindyType.Csv, CsvData.class)
> .aggregate(constant(true), AggregationStrategies.groupedBody())
> .eagerCheckCompletion()
> .executorService(new SynchronousExecutorService())
> .completionSize(BULK_SIZE)
> .completionPredicate(exchangeProperty(SPLIT_COMPLETE))
> .to(direct("saveData"));
> from(direct("saveData"))
> .log("${body}")
> .to(jpa("java.util.List").usePersist(true).flushOnSend(true)); {code}
> With version 4.18.0 everything works fine. With batch size of 5 and a csv of
> 11 lines, 3 batch created and persisted to db in a single database tx.
> With version 4.18.1, after the creation of first chunk the aggregator remains
> stuck and no progression is made
> !image-2026-04-02-00-55-36-946.png!
> The csv is not moved into processed folder and i've to kill the application.
> I've attached a threadump.
> I've created also a small repo to reproduce the issue.
> [spampibridge/split-aggregate|https://github.com/spampibridge/split-aggregate]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
