[ https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17561919#comment-17561919 ]
Michael Rambichler edited comment on CAMEL-18255 at 7/3/22 6:25 PM: -------------------------------------------------------------------- Hi [~davsclaus] The issue is quite independent of MDC. See my example in [https://github.com/michael-salzburg/splitMemoryTest.git] I spend some time to analyse it further: If you override the method of the DefaultUnitOfWork or MDCUnitOfWork and return {color:#de350b}true{color}: Then the Memory Leak occurs. @Override public boolean isBeforeAfterProcess() { {color:#de350b}return true; //like its set e.g. in MDCUnitOfWork{color} } The current MDCUnitOfWork returns true in this case. But i wasn't able to analyse the impact in deep of this change, yet. Btw. You mentioned MDC is low prio/candidate for dprecation: We use MDC logging of especially the breadcrumbId heavily in our system. That would have major impact in our environment. was (Author: rambichler): Hi [~davsclaus] The issue is quite independent of MDC. See my example in [https://github.com/michael-salzburg/splitMemoryTest.git] I spend some time to analyse it further: If you override the method of the DefaultUnitOfWork or MDCUnitOfWork and return {color:#de350b}true{color}: Then the Memory Leak occurs. (Event the @Override public boolean isBeforeAfterProcess() { {color:#de350b}return true; //like its set e.g. in MDCUnitOfWork{color} } The current MDCUnitOfWork returns true in this case. But i wasn't able to analyse the impact in deep of this change, yet. Btw. You mentioned MDC is low prio/candidate for dprecation: We use MDC logging of especially the breadcrumbId heavily in our system. That would have major impact in our environment. > 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)