[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17039506#comment-17039506
]
Pascal Schumacher commented on CAMEL-14579:
-------------------------------------------
Thank you very much for looking into this. It is much appreciated.
I retested with your fix for "CAMEL-14586 camel-core - Disable cache on some
EIPs seems to not be working".
For:
{code:java}
.recipientList(simple("smtp://localhost:1234?to=t...@test.com&mail.smtp.from=${header.smtpFrom}")).cacheSize(-1).end();
{code}
The MailEndpoint leak is fixed, but the RedeliveryPolicy leak remains (see the
attached CamelMail_RecipientList_MemoryLeak_3.1.0-SNAPSHOT-2020-02-18.16.PNG
screenshot).
For dynamic to the behavior is the same as before, but I guess that is as
expected.
By the way: I was able to work around this issue by implementing a custom
JavaMailSender.
> Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
> ----------------------------------------------------------------------------
>
> Key: CAMEL-14579
> URL: https://issues.apache.org/jira/browse/CAMEL-14579
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
> Affects Versions: 3.0.1
> Reporter: Pascal Schumacher
> Priority: Minor
> Attachments: CamelMail_DyamicTo_MemoryLeak-3.1.0-SNAPSHOT.PNG,
> CamelMail_RecipientList_MemoryLeak_3.0.1.PNG,
> CamelMail_RecipientList_MemoryLeak_3.1.0-SNAPSHOT-2020-02-18.16.PNG
>
>
> In Camel 3.0.1 there seems to be a memory leak when you use camel-mail to
> send mails with a recipient list (see attached screenshot
> CamelMail_RecipientList_MemoryLeak_3.0.1.PNG).
> Code to reproduce:
> {code:java}
> public class SendMailDynamicToMemoryLeakTest extends CamelTestSupport {
> @Override
> protected RouteBuilder createRouteBuilder() {
> return new RouteBuilder() {
> public void configure() {
> from("scheduler:start?delay=1")
> .setBody(constant("Hello"))
> .setHeader("smtpFrom", method(UUID.class, "randomUUID"))
>
> .recipientList(simple("smtp://localhost:1234?to=t...@test.com&mail.smtp.from=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com&mail.smtp.from=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
> <dependency>
> <groupId>com.bitmechanic</groupId>
> <artifactId>dumbster</artifactId>
> <version>1.9.0.2</version>
> </dependency>
> {code}
> {code:java}
> public class TestMailServer {
> public static void main(String[] args) throws Exception {
> ServerOptions serverOptions = new ServerOptions();
> serverOptions.port = 1234;
> SmtpServerFactory.startServer(serverOptions);
> }
> }
> {code}
> To make reproduction easier I pushed everything to
> https://github.com/PascalSchumacher/CamelSendMailMemoryLeak
> Run the TestMailServer class, then run SendMailDynamicToMemoryLeakTest.
> Using Camel 3.1.0-SNAPSHOT to run the test shows the same behavior.
> Using Camel 2.24.2 there is no memory leak.
> ---
> The original code is using toD (see commented out code in the test case
> above) instead of a recipient list. For dynamic to there seems to be a slower
> memory leak in Camel 3.0.1 (not completely sure, a lot of objects get garbage
> collected, but overall object count seems to slowly increase.)
> Using Camel 2.24.2 there is no memory leak.
> Using Camel 3.1.0-SNAPSHOT with dynamic to there seems to be a memory leak,
> see the attached screenshot CamelMail_DyamicTo_MemoryLeak-3.1.0-SNAPSHOT.PNG.
> I am not sure if the recipientList/toD behavior is limited to camel-mail or
> if it would occur for other components too. I could not replicate the
> behavior with camel-http, but this component uses optimized dynamic to and
> this may prevent the occurrence of a memory leak.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
