[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17563245#comment-17563245
]
Karen Lease commented on CAMEL-18255:
-------------------------------------
[~rambichler] The root of the problem seems to be in these lines:
[CamelInternalProcessor.java#L405-L411|https://github.com/apache/camel/blob/8f94758145dd26e52b335da6765c46a9d0b95482/core/camel-base-engine/src/main/java/org/apache/camel/impl/engine/CamelInternalProcessor.java#L405-L411]
This puts a lambda to run the afterProcess method on the queue of the
ReactiveExecutor. Each Exchange produced by the splitter is wrapped in a
DefaultErrorHandler but there is already a DefaultErrorHandler wrapping the
processor(s) following the split(). The ErrorHandler queues a SimpleTask using
scheduleMain which backs up any other elements on the queue to a backup queue.
The sequence is a bit difficult to follow but the end result is that the
backed-up queue containing the lambda to run the MDCUnitOfWork.afterProcess()
method is not run when the processing of the Exchange finishes but only when
all Exchanges produced by the split() have been processed. Then they are all
run, but in the reverse order in which they where added to the scheduler! This
causes the memory leak.
The use of the scheduler to run afterProcess() was added back in CAMEL-17153 to
resolve a problem caused by removing it in CAMEL-16034 (which is exactly the
problem you are experiencing.)
I think it might work to invoke the uow.afterProcess() in the async callback
itself, since that task is run at the correct point in the process, so I'm
going to test this approach.
> Memory Leak with MDCUnitOfWork
> ------------------------------
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 3.14.1, 3.17.0
> Reporter: Michael Rambichler
> Priority: Minor
> Fix For: 3.x
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator<String> infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext()
> { return true; }
> @Override public String next()
> { return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
