[
https://issues.apache.org/jira/browse/CAMEL-22147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17987186#comment-17987186
]
Soheila Esmaeili edited comment on CAMEL-22147 at 7/1/25 10:58 AM:
-------------------------------------------------------------------
Hi [~davsclaus]
We’ve found an older ticket with a stack trace that looks very similar to ours.
CAMEL-16938 *StackOverflowError in RedeliveryErrorHandler when using
transacted.* In that ticket, we also saw a your commit message
({*}961ad0e56e9331e71c386415ec67676e586ea629{*}) that might be related.
During our investigation, we found in the code
({*}MulticastProcessor.java:395{*}) that
*reactiveExecutor.scheduleSync(runnable)* is used instead of a
*reactiveExecutor.scheduleQueue(runnable)*
If this is also changed to use a {*}scheduleQueue{*}, it appears to solve the
StackOverFlowError.
At this point, we’re unsure if this was missed in your original commit or if it
was left as sync intentionally due to its impact on other parts of the code.
Could you please confirm?
was (Author: JIRAUSER308495):
Hi [~davsclaus]
We’ve found an older ticket with a stack trace that looks very similar to ours.
[CAMEL-16938] StackOverflowError in RedeliveryErrorHandler when using
transacted - ASF JIRA In that ticket, we also saw a your commit message
({*}961ad0e56e9331e71c386415ec67676e586ea629{*}) that might be related.
During our investigation, we found in the code
({*}MulticastProcessor.java:395{*}) that
*reactiveExecutor.scheduleSync(runnable)* is used instead of a
*reactiveExecutor.scheduleQueue(runnable)*
If this is also changed to use a {*}scheduleQueue{*}, it appears to solve the
StackOverFlowError.
At this point, we’re unsure if this was missed in your original commit or if it
was left as sync intentionally due to its impact on other parts of the code.
Could you please confirm?
> StackOverflowError when Running a Loop with Splitter & Transaction
> ------------------------------------------------------------------
>
> Key: CAMEL-22147
> URL: https://issues.apache.org/jira/browse/CAMEL-22147
> Project: Camel
> Issue Type: Bug
> Components: came-core
> Affects Versions: 4.8.0
> Reporter: Soheila Esmaeili
> Priority: Minor
> Attachments: JdbcLoopTransactedSplitterTest.java,
> image-2025-06-25-13-59-33-912.png
>
>
> I'm encountering a StackOverflowError when running a Camel test that worked
> perfectly fine with \{*}the older (unmaintained – 2.x) Camel version{*}.
> However, after migrating to Camel 3.14 and Camel 4.8, the same test fails:
>
> * In {*}({*}{*}unmaintained{*}{*}){*} *Camel 3.14.7* the process hangs for a
> long time with the following error message and finally terminates with a
> {*}StackOverflowError{*}.
> *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with
> message transform method call failed at
> s\src\java.instrument\share\native\libinstrument\JPLISAgent.c line: 876
> * In {*}Camel 4.8.x{*}, the test is terminated more quickly, but with the
> same error.
> A simplified unit test can be found in the appendix.
> The route uses a loop of 2000 iterations. Each iteration calls a subroute
> which is marked as transacted and contains a split step using XPath.
> The issue seems to be related to transaction boundaries and route recursion
> or resource handling in Camel 3+. There is no explicit recursion in the
> route, but internally Camel may be building a deep call stack due to how it
> handles loop combined with transacted and splitter. The StackOverflowError
> may indicate that each loop iteration adds to the call stack without
> releasing previous frames.
> Could you please confirm if this is a known issue?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
