Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
3.0.1
-
None
-
Unknown
-
Regression
Description
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:
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=test@test.com&mail.smtp.from=${header.smtpFrom}")).cacheSize(-1).end(); // .toD("smtp://localhost:1234?to=test@test.com&mail.smtp.from=${header.smtpFrom}"); } }; } @Test public void test() throws Exception { Thread.sleep(100_000_000L); } }
<dependency> <groupId>com.bitmechanic</groupId> <artifactId>dumbster</artifactId> <version>1.9.0.2</version> </dependency>
public class TestMailServer { public static void main(String[] args) throws Exception { ServerOptions serverOptions = new ServerOptions(); serverOptions.port = 1234; SmtpServerFactory.startServer(serverOptions); } }
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.
Attachments
Attachments
Issue Links
- is related to
-
CAMEL-14594 ProducerServicePool - Memory leak
- Resolved
- relates to
-
CAMEL-14591 Recipient List EIP - MemoryLeak
- Resolved
-
CAMEL-14586 camel-core - Disable cache on some EIPs seems to not be working correlction
- Resolved
-
CAMEL-14595 camel-mail - Allow to use headers for additional mail properties
- Resolved