[jira] [Updated] (CAMEL-13934) camel-minio - Component to store/load files from blob store
[ https://issues.apache.org/jira/browse/CAMEL-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13934: Labels: gsoc2020 (was: ) > camel-minio - Component to store/load files from blob store > --- > > Key: CAMEL-13934 > URL: https://issues.apache.org/jira/browse/CAMEL-13934 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Priority: Major > Labels: gsoc2020 > > min.io is a s3 like blob store. So users have more freedom than being locked > into aws > We can create a camel-minio component for it > https://github.com/minio/minio-java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14495) OPC UA Client samplingInterval parameter seems not take any effect
[
https://issues.apache.org/jira/browse/CAMEL-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14495:
Fix Version/s: 3.2.0
> OPC UA Client samplingInterval parameter seems not take any effect
> --
>
> Key: CAMEL-14495
> URL: https://issues.apache.org/jira/browse/CAMEL-14495
> Project: Camel
> Issue Type: Bug
> Components: camel-milo
>Affects Versions: 2.25.0
>Reporter: Hobbert
>Priority: Minor
> Fix For: 3.2.0
>
>
> When I set the *samplingInterval* parameter on a Milo OPC UA Client route,
> the interval not changes on the real OPC application! Remains 1000 mili
> seconds even after configuring!! Can anyone confirm that??
> Heres my route
> http://camel.apache.org/schema/spring; >
>
> uri="milo-client:tcp://192.168.0.2:4840?samplingInterval=50=RAW(ns=4;i=12)"/>
>
> ${in.body}
>
>
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14495) OPC UA Client samplingInterval parameter seems not take any effect
[
https://issues.apache.org/jira/browse/CAMEL-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14495:
Issue Type: Improvement (was: Bug)
> OPC UA Client samplingInterval parameter seems not take any effect
> --
>
> Key: CAMEL-14495
> URL: https://issues.apache.org/jira/browse/CAMEL-14495
> Project: Camel
> Issue Type: Improvement
> Components: camel-milo
>Affects Versions: 2.25.0
>Reporter: Hobbert
>Priority: Minor
> Fix For: 3.2.0
>
>
> When I set the *samplingInterval* parameter on a Milo OPC UA Client route,
> the interval not changes on the real OPC application! Remains 1000 mili
> seconds even after configuring!! Can anyone confirm that??
> Heres my route
> http://camel.apache.org/schema/spring; >
>
> uri="milo-client:tcp://192.168.0.2:4840?samplingInterval=50=RAW(ns=4;i=12)"/>
>
> ${in.body}
>
>
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14587) AWS Components To Support useIAMCredentials
[ https://issues.apache.org/jira/browse/CAMEL-14587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14587: Fix Version/s: (was: Future) 3.2.0 > AWS Components To Support useIAMCredentials > > > Key: CAMEL-14587 > URL: https://issues.apache.org/jira/browse/CAMEL-14587 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 3.0.0 >Reporter: Bojan Zekanovic >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.2.0 > > > It would be great if we could use useIAMCredentials with other AWS Camel > Components like you guys have it available with S3 Component. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14495) OPC UA Client samplingInterval parameter seems not take any effect
[
https://issues.apache.org/jira/browse/CAMEL-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040655#comment-17040655
]
Claus Ibsen commented on CAMEL-14495:
-
Thanks for diving into this. So you can add a new option to the
MiloClientConfiguration class and then use that in the code you found
> OPC UA Client samplingInterval parameter seems not take any effect
> --
>
> Key: CAMEL-14495
> URL: https://issues.apache.org/jira/browse/CAMEL-14495
> Project: Camel
> Issue Type: Bug
> Components: camel-milo
>Affects Versions: 2.25.0
>Reporter: Hobbert
>Priority: Minor
>
> When I set the *samplingInterval* parameter on a Milo OPC UA Client route,
> the interval not changes on the real OPC application! Remains 1000 mili
> seconds even after configuring!! Can anyone confirm that??
> Heres my route
> http://camel.apache.org/schema/spring; >
>
> uri="milo-client:tcp://192.168.0.2:4840?samplingInterval=50=RAW(ns=4;i=12)"/>
>
> ${in.body}
>
>
>
> Thanks
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14589) camel-cxf - Service beans can only be set via context
[ https://issues.apache.org/jira/browse/CAMEL-14589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14589. - Fix Version/s: 3.1.0 Assignee: Claus Ibsen Resolution: Fixed Thanks for the patch > camel-cxf - Service beans can only be set via context > - > > Key: CAMEL-14589 > URL: https://issues.apache.org/jira/browse/CAMEL-14589 > Project: Camel > Issue Type: Improvement > Components: camel-cxfrs >Affects Versions: 3.0.0, 3.0.1 >Reporter: Jens Kleine-Herzbruch >Assignee: Claus Ibsen >Priority: Minor > Fix For: 3.1.0 > > Attachments: cxf-service-beans.diff > > > Since version 3.x it is no longer possible to set service beans directly. > They can only be resolved from the context instead. This was possible in 2.x. > The attached patch readds this configuration path. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040644#comment-17040644
]
Claus Ibsen commented on CAMEL-14579:
-
Btw the toD with -1 cache size was the only combo i didnt try yesterday evening.
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Resolved] (CAMEL-6950) camel-sjms: Lacks reconnection logic in case of exception
[ https://issues.apache.org/jira/browse/CAMEL-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6950. Resolution: Fixed > camel-sjms: Lacks reconnection logic in case of exception > - > > Key: CAMEL-6950 > URL: https://issues.apache.org/jira/browse/CAMEL-6950 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.12.1 >Reporter: Raúl Kripalani >Priority: Major > Fix For: 3.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > See this thread: > http://camel.465427.n5.nabble.com/SJMS-failure-with-stale-reply-queue-tp5742833.html. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14595) camel-mail - Allow to use headers for additional mail properties
Claus Ibsen created CAMEL-14595: --- Summary: camel-mail - Allow to use headers for additional mail properties Key: CAMEL-14595 URL: https://issues.apache.org/jira/browse/CAMEL-14595 Project: Camel Issue Type: Improvement Components: camel-mail Environment: See CAMEL-14579 We should detect custom headers starting with mail. as key. And then use those in the additional properties map for the mail sender (create new instance so its private). This allows to make the mail more dynamic but reuse same endpoint and producer. Reporter: Claus Ibsen Fix For: 3.2.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-14579.
-
Resolution: Fixed
Okay fixed the NPE. Can you test again with a new build?
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Updated] (CAMEL-6950) camel-sjms: Lacks reconnection logic in case of exception
[ https://issues.apache.org/jira/browse/CAMEL-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6950: --- Fix Version/s: (was: Future) 3.1.0 > camel-sjms: Lacks reconnection logic in case of exception > - > > Key: CAMEL-6950 > URL: https://issues.apache.org/jira/browse/CAMEL-6950 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.12.1 >Reporter: Raúl Kripalani >Priority: Major > Fix For: 3.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > See this thread: > http://camel.465427.n5.nabble.com/SJMS-failure-with-stale-reply-queue-tp5742833.html. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-6950) camel-sjms: Lacks reconnection logic in case of exception
[ https://issues.apache.org/jira/browse/CAMEL-6950?focusedWorklogId=389792=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-389792 ] ASF GitHub Bot logged work on CAMEL-6950: - Author: ASF GitHub Bot Created on: 20/Feb/20 04:48 Start Date: 20/Feb/20 04:48 Worklog Time Spent: 10m Work Description: davsclaus commented on pull request #3581: CAMEL-6950 camel-sjms: Lacks reconnection logic in case of exception URL: https://github.com/apache/camel/pull/3581 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 389792) Time Spent: 20m (was: 10m) > camel-sjms: Lacks reconnection logic in case of exception > - > > Key: CAMEL-6950 > URL: https://issues.apache.org/jira/browse/CAMEL-6950 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.12.1 >Reporter: Raúl Kripalani >Priority: Major > Fix For: Future > > Time Spent: 20m > Remaining Estimate: 0h > > See this thread: > http://camel.465427.n5.nabble.com/SJMS-failure-with-stale-reply-queue-tp5742833.html. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040487#comment-17040487
]
Pascal Schumacher commented on CAMEL-14579:
---
>Okay the leaks has been fixed now.
Yes, with latest master the memory leak has also been fixed for recipient list
with enabled caching and for dynamic to with enabled caching.
However dynamic to with disabled cache still causes a NullPointerException (see
above for details).
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040471#comment-17040471
]
Pascal Schumacher commented on CAMEL-14579:
---
>Okay working on the producer cache leak. However all the others has been
>fixed, so if you run with -1 as cache size then there should be no leak for
>both recipient list or toD.
Yes, there is no memory leak for
{code:java}
.toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}",
-1)
{code}
anymore. Thanks!
Mails are sent, but a lot of NullPointerExceptions occur:
{noformat}
22:55:32.779 [Camel (camel-1) thread #1 - scheduler://start] ERROR
org.apache.camel.processor.errorhandler.DefaultErrorHandler - Failed delivery
for (MessageId: ID-Redhawk-THINK-1582149325759-0-332 on ExchangeId:
ID-Redhawk-THINK-1582149325759-0-332). Exhausted after delivery attempt: 1
caught: java.lang.NullPointerException
Message History (complete message history is disabled)
---
RouteId ProcessorId Processor
Elapsed (ms)
[route1] [route1] [from[scheduler://start?delay=1]
] [ 0]
...
[route1] [toD1 ]
[smtp://localhost:xxx...@test.com=${header.smtpFrom}
] [ 0]
Stacktrace
---
java.lang.NullPointerException: null
at
org.apache.camel.impl.engine.DefaultProducerCache.lambda$doInAsyncProducer$4(DefaultProducerCache.java:318)
at
org.apache.camel.processor.SendDynamicProcessor$1.done(SendDynamicProcessor.java:195)
at
org.apache.camel.support.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:73)
at
org.apache.camel.processor.SendDynamicProcessor.lambda$process$0(SendDynamicProcessor.java:183)
at
org.apache.camel.impl.engine.DefaultProducerCache.doInAsyncProducer(DefaultProducerCache.java:309)
at
org.apache.camel.processor.SendDynamicProcessor.process(SendDynamicProcessor.java:168)
at
org.apache.camel.processor.errorhandler.RedeliveryErrorHandler$SimpleTask.run(RedeliveryErrorHandler.java:396)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:153)
at
org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:60)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:147)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:286)
at
org.apache.camel.component.scheduler.SchedulerConsumer.sendTimerExchange(SchedulerConsumer.java:58)
at
org.apache.camel.component.scheduler.SchedulerConsumer.poll(SchedulerConsumer.java:43)
at
org.apache.camel.support.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:187)
at
org.apache.camel.support.ScheduledPollConsumer.run(ScheduledPollConsumer.java:106)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
22:55:32.779 [Camel (camel-1) thread #1 - scheduler://start] WARN
org.apache.camel.component.scheduler.SchedulerConsumer - Error processing
exchange. Exchange[ID-Redhawk-THINK-1582149325759-0-332]. Caused by:
[java.lang.NullPointerException - null]
java.lang.NullPointerException: null
at
org.apache.camel.impl.engine.DefaultProducerCache.lambda$doInAsyncProducer$4(DefaultProducerCache.java:318)
at
org.apache.camel.processor.SendDynamicProcessor$1.done(SendDynamicProcessor.java:195)
at
org.apache.camel.support.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:73)
at
org.apache.camel.processor.SendDynamicProcessor.lambda$process$0(SendDynamicProcessor.java:183)
at
org.apache.camel.impl.engine.DefaultProducerCache.doInAsyncProducer(DefaultProducerCache.java:309)
at
org.apache.camel.processor.SendDynamicProcessor.process(SendDynamicProcessor.java:168)
at
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040467#comment-17040467
]
Claus Ibsen commented on CAMEL-14579:
-
Okay the leaks has been fixed now.
Pascal, you are welcome to re-test.
About mail.smtp.from then we can look at adding support for headers so you can
use a static endpoint but the headers can then provide dynamic values where we
then re-create a mail sender.
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Resolved] (CAMEL-14594) ProducerServicePool - Memory leak
[ https://issues.apache.org/jira/browse/CAMEL-14594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14594. - Resolution: Fixed > ProducerServicePool - Memory leak > - > > Key: CAMEL-14594 > URL: https://issues.apache.org/jira/browse/CAMEL-14594 > Project: Camel > Issue Type: Bug >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040389#comment-17040389
]
Claus Ibsen commented on CAMEL-14579:
-
Okay working on the producer cache leak. However all the others has been fixed,
so if you run with -1 as cache size then there should be no leak for both
recipient list or toD.
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040378#comment-17040378
]
Pascal Schumacher commented on CAMEL-14579:
---
Sure I can retest either later today or tomorrow. Just let me know when to do
it.
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Resolved] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14590. - Fix Version/s: (was: 3.2.0) 3.1.0 Resolution: Fixed Thanks for reporting and the PR > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > Fix For: 3.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14593) Eager type converter creation breaks WildFly integration
[
https://issues.apache.org/jira/browse/CAMEL-14593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-14593.
-
Fix Version/s: 3.1.0
Resolution: Fixed
> Eager type converter creation breaks WildFly integration
>
>
> Key: CAMEL-14593
> URL: https://issues.apache.org/jira/browse/CAMEL-14593
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Fix For: 3.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Below we have a callback to the wildfly-camel integration that registers
> additional PackageScanClassResolvers, which are able scan stuff on a modules
> classpath.
>
> {code:java}
> // Call all registered trackers with this context
> // Note, this may use a partially constructed object
> CamelContextTracker.notifyContextCreated(this);
> {code}
> Doing this after creating the type converters, results in camel not seeing
> converters from the deployment module. Other stuff may also be missing.
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/2951
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CAMEL-14588) MailConsumer: Move mail after processing
[ https://issues.apache.org/jira/browse/CAMEL-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14588. - Fix Version/s: (was: 3.2.0) 3.1.0 Resolution: Fixed Thanks for the PR > MailConsumer: Move mail after processing > > > Key: CAMEL-14588 > URL: https://issues.apache.org/jira/browse/CAMEL-14588 > Project: Camel > Issue Type: New Feature > Components: camel-mail >Reporter: Manuel Shenavai >Priority: Major > Fix For: 3.1.0 > > Attachments: 0001-New-property-MoveTo.patch > > Time Spent: 20m > Remaining Estimate: 0h > > After processing a mail with the mailConsumer, I like to mark the message as > read and move it to another folder. > > I attached a proposal how to add this feature. Kindly have a look. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-14591. - Resolution: Fixed > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14594) ProducerServicePool - Memory leak
Claus Ibsen created CAMEL-14594: --- Summary: ProducerServicePool - Memory leak Key: CAMEL-14594 URL: https://issues.apache.org/jira/browse/CAMEL-14594 Project: Camel Issue Type: Bug Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.1.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040365#comment-17040365 ] Claus Ibsen commented on CAMEL-14591: - Okay fixed the error handler builder leak, but there is actually another issue in the ProducerServicePool > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14588) MailConsumer: Move mail after processing
[ https://issues.apache.org/jira/browse/CAMEL-14588?focusedWorklogId=389573=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-389573 ] ASF GitHub Bot logged work on CAMEL-14588: -- Author: ASF GitHub Bot Created on: 19/Feb/20 19:22 Start Date: 19/Feb/20 19:22 Worklog Time Spent: 10m Work Description: davsclaus commented on pull request #3587: CAMEL-14588: New setting to allow mails to be moved after processing URL: https://github.com/apache/camel/pull/3587 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 389573) Time Spent: 20m (was: 10m) > MailConsumer: Move mail after processing > > > Key: CAMEL-14588 > URL: https://issues.apache.org/jira/browse/CAMEL-14588 > Project: Camel > Issue Type: New Feature > Components: camel-mail >Reporter: Manuel Shenavai >Priority: Major > Fix For: 3.2.0 > > Attachments: 0001-New-property-MoveTo.patch > > Time Spent: 20m > Remaining Estimate: 0h > > After processing a mail with the mailConsumer, I like to mark the message as > read and move it to another folder. > > I attached a proposal how to add this feature. Kindly have a look. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?focusedWorklogId=389572=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-389572 ] ASF GitHub Bot logged work on CAMEL-14590: -- Author: ASF GitHub Bot Created on: 19/Feb/20 19:21 Start Date: 19/Feb/20 19:21 Worklog Time Spent: 10m Work Description: davsclaus commented on pull request #3591: CAMEL-14590 Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription URL: https://github.com/apache/camel/pull/3591 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 389572) Time Spent: 20m (was: 10m) > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > Fix For: 3.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14593) Eager type converter creation breaks WildFly integration
[
https://issues.apache.org/jira/browse/CAMEL-14593?focusedWorklogId=389571=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-389571
]
ASF GitHub Bot logged work on CAMEL-14593:
--
Author: ASF GitHub Bot
Created on: 19/Feb/20 19:21
Start Date: 19/Feb/20 19:21
Worklog Time Spent: 10m
Work Description: davsclaus commented on pull request #3590:
[CAMEL-14593] Eager type converter creation breaks WildFly integration
URL: https://github.com/apache/camel/pull/3590
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 389571)
Time Spent: 20m (was: 10m)
> Eager type converter creation breaks WildFly integration
>
>
> Key: CAMEL-14593
> URL: https://issues.apache.org/jira/browse/CAMEL-14593
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Below we have a callback to the wildfly-camel integration that registers
> additional PackageScanClassResolvers, which are able scan stuff on a modules
> classpath.
>
> {code:java}
> // Call all registered trackers with this context
> // Note, this may use a partially constructed object
> CamelContextTracker.notifyContextCreated(this);
> {code}
> Doing this after creating the type converters, results in camel not seeing
> converters from the deployment module. Other stuff may also be missing.
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/2951
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040300#comment-17040300 ] Claus Ibsen commented on CAMEL-14590: - Okay you are welcome to do a PR against master and if you are quick we can get this into 3.1.0 release > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > Fix For: 3.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040238#comment-17040238 ] Masa commented on CAMEL-14590: -- I believe we should remove the unsubscribe call entirely and not make it configurable. We do not want to destroy subscriptions when the application is shutdown or a route is restarted. "Unsubscribe" should be Pulsar admin functionality and not part of a Camel component. > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > Fix For: 3.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?focusedWorklogId=389484=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-389484 ] ASF GitHub Bot logged work on CAMEL-14590: -- Author: ASF GitHub Bot Created on: 19/Feb/20 16:16 Start Date: 19/Feb/20 16:16 Worklog Time Spent: 10m Work Description: connormcauliffe-toast commented on pull request #3591: CAMEL-14590 Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription URL: https://github.com/apache/camel/pull/3591 In the PulsarUtils stopConsumers method all the consumers call unsubscribe(). This causes the subscription to be deleted if this call comes from the last consumer. The PR makes the unsubscribe call configurable so that unwanted subscription deletion can be prevented. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 389484) Remaining Estimate: 0h Time Spent: 10m > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > Fix For: 3.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (CAMEL-14593) Eager type converter creation breaks WildFly integration
[
https://issues.apache.org/jira/browse/CAMEL-14593?focusedWorklogId=389482=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-389482
]
ASF GitHub Bot logged work on CAMEL-14593:
--
Author: ASF GitHub Bot
Created on: 19/Feb/20 16:12
Start Date: 19/Feb/20 16:12
Worklog Time Spent: 10m
Work Description: tdiesler commented on pull request #3590: [CAMEL-14593]
Eager type converter creation breaks WildFly integration
URL: https://github.com/apache/camel/pull/3590
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 389482)
Remaining Estimate: 0h
Time Spent: 10m
> Eager type converter creation breaks WildFly integration
>
>
> Key: CAMEL-14593
> URL: https://issues.apache.org/jira/browse/CAMEL-14593
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Below we have a callback to the wildfly-camel integration that registers
> additional PackageScanClassResolvers, which are able scan stuff on a modules
> classpath.
>
> {code:java}
> // Call all registered trackers with this context
> // Note, this may use a partially constructed object
> CamelContextTracker.notifyContextCreated(this);
> {code}
> Doing this after creating the type converters, results in camel not seeing
> converters from the deployment module. Other stuff may also be missing.
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/2951
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-12953) Camel grpc component doesn't transfer the Message headers
[ https://issues.apache.org/jira/browse/CAMEL-12953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040176#comment-17040176 ] Dmitry Volodin edited comment on CAMEL-12953 at 2/19/20 4:08 PM: - Hi [~dmvolod], Thanks for the response. I will go through the website. Actually I would like to consider this issue and this one for the GSOC CAMEL-11994 Cheers, Madhawa was (Author: madhawak): Hi [~dmvolod], Thanks for the response. I will go through the website. Actually I would like to consider this issue and this one for the GSOC https://issues.apache.org/jira/browse/CAMEL-11994 Cheers, Madhawa > Camel grpc component doesn't transfer the Message headers > - > > Key: CAMEL-12953 > URL: https://issues.apache.org/jira/browse/CAMEL-12953 > Project: Camel > Issue Type: New Feature > Components: camel-grpc >Affects Versions: 2.22.1 >Reporter: Vishal Vijayan >Priority: Major > Labels: gsoc2020 > Fix For: 3.x > > > Headers that are added to the Message in the camel Exchange before making a > call to the camel-grpc component are not received at the grpc consumer. The > expectation is that these headers would be added to the grpcStub before > sending over the wire (like other components like http4 etc). > Our team has come up with a workaround for this but it is extremely > cumbersome. We had to extend the GrpcProducer to introduce a custom > GrpcExchangeForwarder that would copy header from exchange to the stub before > invoking the sync/async method. > At the consumer side we had to extend the GrpcConsumer to use a custom > ServerInterceptor to capture the grpc headers and custom MethodHandler to > transfer the grpc headers to the Camel exchange headers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14593) Eager type converter creation breaks WildFly integration
[
https://issues.apache.org/jira/browse/CAMEL-14593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Diesler updated CAMEL-14593:
---
Description:
Below we have a callback to the wildfly-camel integration that registers
additional PackageScanClassResolvers, which are able scan stuff on a modules
classpath.
{code:java}
// Call all registered trackers with this context
// Note, this may use a partially constructed object
CamelContextTracker.notifyContextCreated(this);
{code}
Doing this after creating the type converters, results in camel not seeing
converters from the deployment module. Other stuff may also be missing.
CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/2951
was:
Below we have a callback to the wildfly-camel integration that registers
additional PackageScanClassResolvers, which are able scan stuff on a modules
classpath.
{code:java}
// Call all registered trackers with this context
// Note, this may use a partially constructed object
CamelContextTracker.notifyContextCreated(this);
{code}
Doing this after creating the type converters, results in camel not seeing
converters from the deployment module. Other stuff may also be missing.
> Eager type converter creation breaks WildFly integration
>
>
> Key: CAMEL-14593
> URL: https://issues.apache.org/jira/browse/CAMEL-14593
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
>
> Below we have a callback to the wildfly-camel integration that registers
> additional PackageScanClassResolvers, which are able scan stuff on a modules
> classpath.
>
> {code:java}
> // Call all registered trackers with this context
> // Note, this may use a partially constructed object
> CamelContextTracker.notifyContextCreated(this);
> {code}
> Doing this after creating the type converters, results in camel not seeing
> converters from the deployment module. Other stuff may also be missing.
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/2951
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14593) Eager type converter creation breaks WildFly integration
Thomas Diesler created CAMEL-14593:
--
Summary: Eager type converter creation breaks WildFly integration
Key: CAMEL-14593
URL: https://issues.apache.org/jira/browse/CAMEL-14593
Project: Camel
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Thomas Diesler
Assignee: Thomas Diesler
Below we have a callback to the wildfly-camel integration that registers
additional PackageScanClassResolvers, which are able scan stuff on a modules
classpath.
{code}
{{// Call all registered trackers with this context
// Note, this may use a partially constructed object
CamelContextTracker.notifyContextCreated(this); }}
{code}
{{}}
Doing this after creating the type converters, results in camel not seeing
converters from the deployment module. Other stuff may also be missing.
[!https://avatars2.githubusercontent.com/u/244946?s=56=4|width=28,height=28!|https://github.com/tdiesler]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14593) Eager type converter creation breaks WildFly integration
[
https://issues.apache.org/jira/browse/CAMEL-14593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Diesler updated CAMEL-14593:
---
Description:
Below we have a callback to the wildfly-camel integration that registers
additional PackageScanClassResolvers, which are able scan stuff on a modules
classpath.
{code:java}
// Call all registered trackers with this context
// Note, this may use a partially constructed object
CamelContextTracker.notifyContextCreated(this);
{code}
Doing this after creating the type converters, results in camel not seeing
converters from the deployment module. Other stuff may also be missing.
was:
Below we have a callback to the wildfly-camel integration that registers
additional PackageScanClassResolvers, which are able scan stuff on a modules
classpath.
{code}
{{// Call all registered trackers with this context
// Note, this may use a partially constructed object
CamelContextTracker.notifyContextCreated(this); }}
{code}
{{}}
Doing this after creating the type converters, results in camel not seeing
converters from the deployment module. Other stuff may also be missing.
[!https://avatars2.githubusercontent.com/u/244946?s=56=4|width=28,height=28!|https://github.com/tdiesler]
> Eager type converter creation breaks WildFly integration
>
>
> Key: CAMEL-14593
> URL: https://issues.apache.org/jira/browse/CAMEL-14593
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
>Priority: Major
>
> Below we have a callback to the wildfly-camel integration that registers
> additional PackageScanClassResolvers, which are able scan stuff on a modules
> classpath.
>
> {code:java}
> // Call all registered trackers with this context
> // Note, this may use a partially constructed object
> CamelContextTracker.notifyContextCreated(this);
> {code}
> Doing this after creating the type converters, results in camel not seeing
> converters from the deployment module. Other stuff may also be missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-12953) Camel grpc component doesn't transfer the Message headers
[ https://issues.apache.org/jira/browse/CAMEL-12953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040176#comment-17040176 ] Madhawa Gunasekara edited comment on CAMEL-12953 at 2/19/20 3:48 PM: - Hi [~dmvolod], Thanks for the response. I will go through the website. Actually I would like to consider this issue and this one for the GSOC https://issues.apache.org/jira/browse/CAMEL-11994 Cheers, Madhawa was (Author: madhawak): Hi [~dmvolod], Thanks for the response. I will go through the website. Cheers, Madhawa > Camel grpc component doesn't transfer the Message headers > - > > Key: CAMEL-12953 > URL: https://issues.apache.org/jira/browse/CAMEL-12953 > Project: Camel > Issue Type: New Feature > Components: camel-grpc >Affects Versions: 2.22.1 >Reporter: Vishal Vijayan >Priority: Major > Labels: gsoc2020 > Fix For: 3.x > > > Headers that are added to the Message in the camel Exchange before making a > call to the camel-grpc component are not received at the grpc consumer. The > expectation is that these headers would be added to the grpcStub before > sending over the wire (like other components like http4 etc). > Our team has come up with a workaround for this but it is extremely > cumbersome. We had to extend the GrpcProducer to introduce a custom > GrpcExchangeForwarder that would copy header from exchange to the stub before > invoking the sync/async method. > At the consumer side we had to extend the GrpcConsumer to use a custom > ServerInterceptor to capture the grpc headers and custom MethodHandler to > transfer the grpc headers to the Camel exchange headers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-12953) Camel grpc component doesn't transfer the Message headers
[ https://issues.apache.org/jira/browse/CAMEL-12953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040176#comment-17040176 ] Madhawa Gunasekara commented on CAMEL-12953: Hi [~dmvolod], Thanks for the response. I will go through the website. Cheers, Madhawa > Camel grpc component doesn't transfer the Message headers > - > > Key: CAMEL-12953 > URL: https://issues.apache.org/jira/browse/CAMEL-12953 > Project: Camel > Issue Type: New Feature > Components: camel-grpc >Affects Versions: 2.22.1 >Reporter: Vishal Vijayan >Priority: Major > Labels: gsoc2020 > Fix For: 3.x > > > Headers that are added to the Message in the camel Exchange before making a > call to the camel-grpc component are not received at the grpc consumer. The > expectation is that these headers would be added to the grpcStub before > sending over the wire (like other components like http4 etc). > Our team has come up with a workaround for this but it is extremely > cumbersome. We had to extend the GrpcProducer to introduce a custom > GrpcExchangeForwarder that would copy header from exchange to the stub before > invoking the sync/async method. > At the consumer side we had to extend the GrpcConsumer to use a custom > ServerInterceptor to capture the grpc headers and custom MethodHandler to > transfer the grpc headers to the Camel exchange headers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040169#comment-17040169 ] Claus Ibsen commented on CAMEL-14591: - Okay working on a better solution which looks promising > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14590: Fix Version/s: 3.2.0 > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Bug > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > Fix For: 3.2.0 > > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14590: Issue Type: Improvement (was: Bug) > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > Fix For: 3.2.0 > > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040161#comment-17040161 ] Claus Ibsen commented on CAMEL-14590: - Yeah it sounds like a good idea to have an option to configure if unsubscribe should be called on stop or not, and then turn it off so it wont delete the subscription. > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Bug > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040143#comment-17040143 ] Andrea Cosentino commented on CAMEL-14590: -- I do believe we need to review the mechanism in this case. The history of this component is more or less this: there were a couple of contributors already working on this, they were using this component in their daily job and they submitted it. There is space for improving this for sure. So you're welcome. Thanks for the documentation too. > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Bug > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040119#comment-17040119 ] Connor McAuliffe commented on CAMEL-14590: -- I was thinking about that as well but then the subscription would still get deleted on a graceful shutdown (from what I can tell, don't know all the underlying routing but it looks like shutdown just calls stop). Which also seems dangerous or maybe unintentional? > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Bug > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040116#comment-17040116 ] Andrea Cosentino commented on CAMEL-14590: -- Probably the real misuse is doing this in doResume and doSuspend, I guess > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Bug > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[
https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040117#comment-17040117
]
Connor McAuliffe commented on CAMEL-14590:
--
To expand a little on the pulsar side of this:
In the lifecycle of the subscription according to pulsar, "Subscriptions can be
dropped by explicitly unsubscribing (in {{Consumer}} API) or through the
REST/CLI"
[https://github.com/apache/pulsar/blob/master/faq.md#what-is-the-lifecycle-of-subscription]
In persistent subscriptions, unsubscribe calls delete on the subscription if
the consumer is the last consumer
[https://github.com/apache/pulsar/blob/2e30c086b2461531c62164d09ea148928a0e3ae6/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentSubscription.java#L889]
So calling unsubscribe is basically like deleting the subscription, and not
removing the consumer from the subscription
> Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially
> deleting subscription
> --
>
> Key: CAMEL-14590
> URL: https://issues.apache.org/jira/browse/CAMEL-14590
> Project: Camel
> Issue Type: Bug
> Components: camel-pulsar
>Reporter: Connor McAuliffe
>Priority: Major
>
> In the PulsarUtils [stopConsumers
> method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java]
> all the consumers call unsubscribe(). This causes the subscription to be
> deleted if this call comes from the last consumer. I do not know if this is
> intentional behavior but it seems to be dangerous (and has caused some issues
> for us without realizing it). If this is intentional, can we make it
> configurable to avoid doing this? Or if it is not intentional can we just
> remove the call entirely?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-13564) Split exception/error handling model from runtime
[ https://issues.apache.org/jira/browse/CAMEL-13564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13564: Fix Version/s: (was: 3.0.2) 3.0.0 > Split exception/error handling model from runtime > - > > Key: CAMEL-13564 > URL: https://issues.apache.org/jira/browse/CAMEL-13564 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-13564) Split exception/error handling model from runtime
[ https://issues.apache.org/jira/browse/CAMEL-13564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13564: Fix Version/s: (was: 3.x) 3.0.2 > Split exception/error handling model from runtime > - > > Key: CAMEL-13564 > URL: https://issues.apache.org/jira/browse/CAMEL-13564 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.0.2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040103#comment-17040103 ] Connor McAuliffe commented on CAMEL-14590: -- The problem we are seeing is that unsubscribe does more than just stop the consumer, it deletes the subscription if that consumer is the last consumer. So if for some reason a route stops (we were playing around with dynamically starting and stopping a route) the subscription, and more importantly the cursor, get removed. Then when the route starts again it creates a new subscription, meaning that you either have to use the earliest subscription position and reprocess every message in the topic or use latest and miss every message that was sent between when the route was stopped and started. I think the method unsubscribe is poorly named given its functionality and not documented well but that's a pulsar issue. I am working on making a PR to make this configurable via camel but if you think it sounds like a misuse then I would be more than happy to just remove the call to unsubscribe altogether. > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Bug > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14532) Fix issues with camel-snakeyaml
[ https://issues.apache.org/jira/browse/CAMEL-14532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CAMEL-14532. - Resolution: Fixed > Fix issues with camel-snakeyaml > > > Key: CAMEL-14532 > URL: https://issues.apache.org/jira/browse/CAMEL-14532 > Project: Camel > Issue Type: Task > Components: camel-snakeyaml >Reporter: Claus Ibsen >Assignee: Colm O hEigeartaigh >Priority: Major > Fix For: 3.1.0, 3.0.2, 2.25.1 > > > There is an issue with this library that can cause endless recursion. A PR > has been submitted upstream, however we can work around it in Camel until > (if) it is applied. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14590) Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially deleting subscription
[ https://issues.apache.org/jira/browse/CAMEL-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040074#comment-17040074 ] Andrea Cosentino commented on CAMEL-14590: -- What is the problem you've seen? To me stopping the consumers on doStop, it's completely fine. > Camel-Pulsar consumer calls unsubscribe on doStop/doSuspend, potentially > deleting subscription > -- > > Key: CAMEL-14590 > URL: https://issues.apache.org/jira/browse/CAMEL-14590 > Project: Camel > Issue Type: Bug > Components: camel-pulsar >Reporter: Connor McAuliffe >Priority: Major > > In the PulsarUtils [stopConsumers > method|https://github.com/apache/camel/blob/master/components/camel-pulsar/src/main/java/org/apache/camel/component/pulsar/utils/PulsarUtils.java] > all the consumers call unsubscribe(). This causes the subscription to be > deleted if this call comes from the last consumer. I do not know if this is > intentional behavior but it seems to be dangerous (and has caused some issues > for us without realizing it). If this is intentional, can we make it > configurable to avoid doing this? Or if it is not intentional can we just > remove the call entirely? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040037#comment-17040037 ] Claus Ibsen commented on CAMEL-14591: - Argh danm there was some new issues so have to look into finding a better solution > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040015#comment-17040015
]
Claus Ibsen commented on CAMEL-14579:
-
Pascal, I likely have a fix and have tested it with your sample project, and
the GC can go down to low again. But it would be good if you could run a test
too, when I have pushed the changes.
This should work with and without setting cacheSize(-1) or not on both EIPs
(toD support it too).
So when I have pushed then I will commented again and if you could test asap
then that would be great as we want to build the release asap after
verification.
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Commented] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040013#comment-17040013 ] Claus Ibsen commented on CAMEL-14591: - Okay have a potential solution, need additional testing before pushing > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039951#comment-17039951 ] Claus Ibsen commented on CAMEL-14591: - Okay so the memory leak is fine grained error handling with recipient list which is also what we expected. Turning this off makes the leak go away. > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039906#comment-17039906 ] Claus Ibsen edited comment on CAMEL-14591 at 2/19/20 11:02 AM: --- There is also a thread pool that the recipinent list uses for timeout handling, that potentially is not shutdown, and created even if timeout is not in use. *DONE* was (Author: davsclaus): There is also a thread pool that the recipinent list uses for timeout handling, that potentially is not shutdown, and created even if timeout is not in use. > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14591: Priority: Critical (was: Major) > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Critical > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14591) Recipient List EIP - MemoryLeak
[ https://issues.apache.org/jira/browse/CAMEL-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039906#comment-17039906 ] Claus Ibsen commented on CAMEL-14591: - There is also a thread pool that the recipinent list uses for timeout handling, that potentially is not shutdown, and created even if timeout is not in use. > Recipient List EIP - MemoryLeak > --- > > Key: CAMEL-14591 > URL: https://issues.apache.org/jira/browse/CAMEL-14591 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 3.1.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14592) Correct the camel-gson documentation
Alex Dettinger created CAMEL-14592: -- Summary: Correct the camel-gson documentation Key: CAMEL-14592 URL: https://issues.apache.org/jira/browse/CAMEL-14592 Project: Camel Issue Type: Task Reporter: Alex Dettinger The doc says GsonDataFormat implements a useList() method according to [https://github.com/apache/camel/blob/master/components/camel-jackson/src/main/docs/json-jackson-dataformat.adoc.|https://github.com/apache/camel/blob/master/components/camel-jackson/src/main/docs/json-jackson-dataformat.adoc] But, it turns out this is not true. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14592) Correct the camel-gson documentation
[ https://issues.apache.org/jira/browse/CAMEL-14592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Dettinger updated CAMEL-14592: --- Affects Version/s: 3.1.0 > Correct the camel-gson documentation > > > Key: CAMEL-14592 > URL: https://issues.apache.org/jira/browse/CAMEL-14592 > Project: Camel > Issue Type: Task > Components: camel-gson >Affects Versions: 3.1.0 >Reporter: Alex Dettinger >Priority: Minor > > The doc says GsonDataFormat implements a useList() method according to > [https://github.com/apache/camel/blob/master/components/camel-jackson/src/main/docs/json-jackson-dataformat.adoc.|https://github.com/apache/camel/blob/master/components/camel-jackson/src/main/docs/json-jackson-dataformat.adoc] > But, it turns out this is not true. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14592) Correct the camel-gson documentation
[ https://issues.apache.org/jira/browse/CAMEL-14592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Dettinger updated CAMEL-14592: --- Component/s: camel-gson > Correct the camel-gson documentation > > > Key: CAMEL-14592 > URL: https://issues.apache.org/jira/browse/CAMEL-14592 > Project: Camel > Issue Type: Task > Components: camel-gson >Reporter: Alex Dettinger >Priority: Minor > > The doc says GsonDataFormat implements a useList() method according to > [https://github.com/apache/camel/blob/master/components/camel-jackson/src/main/docs/json-jackson-dataformat.adoc.|https://github.com/apache/camel/blob/master/components/camel-jackson/src/main/docs/json-jackson-dataformat.adoc] > But, it turns out this is not true. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039857#comment-17039857
]
Claus Ibsen commented on CAMEL-14579:
-
Have reproduced the issue with recipient list EIP and created a new ticket for
it
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Created] (CAMEL-14591) Recipient List EIP - MemoryLeak
Claus Ibsen created CAMEL-14591: --- Summary: Recipient List EIP - MemoryLeak Key: CAMEL-14591 URL: https://issues.apache.org/jira/browse/CAMEL-14591 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 3.1.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.1.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-14579:
Fix Version/s: 3.1.0
> 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
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.1.0
>
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Assigned] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-14579:
---
Assignee: Claus Ibsen
> 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
>Assignee: Claus Ibsen
>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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
[jira] [Commented] (CAMEL-14579) Camel-mail: MemoryLeak when sending mails using recipient list or dynamic to
[
https://issues.apache.org/jira/browse/CAMEL-14579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039798#comment-17039798
]
Claus Ibsen commented on CAMEL-14579:
-
Dynamic to also has a cacheSize which you can set to -1 to disable it like
recipient list.
About the RedeliveryPolicy then I will investigate. Thanks for spotting this.
> 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=${header.smtpFrom}")).cacheSize(-1).end();
> //
> .toD("smtp://localhost:1234?to=t...@test.com=${header.smtpFrom}");
> }
> };
> }
> @Test
> public void test() throws Exception {
> Thread.sleep(100_000_000L);
> }
> }
> {code}
> {code:xml}
>
> com.bitmechanic
> dumbster
> 1.9.0.2
>
> {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)
