[jira] [Commented] (CAMEL-18093) camel-http - Add option to turn on follow redirects
[
https://issues.apache.org/jira/browse/CAMEL-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561707#comment-17561707
]
Claus Ibsen commented on CAMEL-18093:
-
Yes you are welcome
> camel-http - Add option to turn on follow redirects
> ---
>
> Key: CAMEL-18093
> URL: https://issues.apache.org/jira/browse/CAMEL-18093
> Project: Camel
> Issue Type: New Feature
> Components: camel-http
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 3.x
>
>
> With your hint, I have found the solution: httpClientConfigure
> from("direct:start")
>
> .to("rest:POST:users/{id}/basic?throwExceptionOnFailure=false=#customConfigurer")
> .log(LoggingLevel.INFO, "Received body : ${body}")
> .to("mock:result");
> @BindToRegistry("customConfigurer")
> private TestClientConfigurer testConfigurer;
> private static class TestClientConfigurer implements HttpClientConfigurer {
> @Overridepublic void configureHttpClient(HttpClientBuilder
> clientBuilder) {
> clientBuilder.setRedirectStrategy(new LaxRedirectStrategy());}
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18170) Add serviceAccountKey parameter to google components
[
https://issues.apache.org/jira/browse/CAMEL-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18170:
Fix Version/s: 3.18.0
(was: 3.19.0)
> Add serviceAccountKey parameter to google components
>
>
> Key: CAMEL-18170
> URL: https://issues.apache.org/jira/browse/CAMEL-18170
> Project: Camel
> Issue Type: Improvement
> Components: camel-google-calendar, camel-google-drive,
> camel-google-mail, camel-google-sheets
>Reporter: Claudio Miranda
>Assignee: Otavio Rodolfo Piske
>Priority: Minor
> Fix For: 3.18.0
>
>
> Add support to use {{service account key}} parameter to google components:
> sheets, calendar, mail, drive.
> Similar to google bigquery component.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18170) Add serviceAccountKey parameter to google components
[
https://issues.apache.org/jira/browse/CAMEL-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-18170.
-
Resolution: Fixed
> Add serviceAccountKey parameter to google components
>
>
> Key: CAMEL-18170
> URL: https://issues.apache.org/jira/browse/CAMEL-18170
> Project: Camel
> Issue Type: Improvement
> Components: camel-google-calendar, camel-google-drive,
> camel-google-mail, camel-google-sheets
>Reporter: Claudio Miranda
>Assignee: Otavio Rodolfo Piske
>Priority: Minor
> Fix For: 3.18.0
>
>
> Add support to use {{service account key}} parameter to google components:
> sheets, calendar, mail, drive.
> Similar to google bigquery component.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18093) camel-http - Add option to turn on follow redirects
[
https://issues.apache.org/jira/browse/CAMEL-18093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561628#comment-17561628
]
Rhuan Rocha commented on CAMEL-18093:
-
Hi [~davsclaus],
I will get this issue to contribute, okay?
> camel-http - Add option to turn on follow redirects
> ---
>
> Key: CAMEL-18093
> URL: https://issues.apache.org/jira/browse/CAMEL-18093
> Project: Camel
> Issue Type: New Feature
> Components: camel-http
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 3.x
>
>
> With your hint, I have found the solution: httpClientConfigure
> from("direct:start")
>
> .to("rest:POST:users/{id}/basic?throwExceptionOnFailure=false=#customConfigurer")
> .log(LoggingLevel.INFO, "Received body : ${body}")
> .to("mock:result");
> @BindToRegistry("customConfigurer")
> private TestClientConfigurer testConfigurer;
> private static class TestClientConfigurer implements HttpClientConfigurer {
> @Overridepublic void configureHttpClient(HttpClientBuilder
> clientBuilder) {
> clientBuilder.setRedirectStrategy(new LaxRedirectStrategy());}
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18170) Add serviceAccountKey parameter to google components
[
https://issues.apache.org/jira/browse/CAMEL-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561624#comment-17561624
]
Rhuan Rocha edited comment on CAMEL-18170 at 7/1/22 9:31 PM:
-
Hi [~davsclaus]
No. You can close this ticket, as the components were updated
was (Author: rhuanrcoha):
Hi [~davsclaus]
No. I will close this ticket, as the components were updated.
> Add serviceAccountKey parameter to google components
>
>
> Key: CAMEL-18170
> URL: https://issues.apache.org/jira/browse/CAMEL-18170
> Project: Camel
> Issue Type: Improvement
> Components: camel-google-calendar, camel-google-drive,
> camel-google-mail, camel-google-sheets
>Reporter: Claudio Miranda
>Assignee: Otavio Rodolfo Piske
>Priority: Minor
> Fix For: 3.19.0
>
>
> Add support to use {{service account key}} parameter to google components:
> sheets, calendar, mail, drive.
> Similar to google bigquery component.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18170) Add serviceAccountKey parameter to google components
[
https://issues.apache.org/jira/browse/CAMEL-18170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561624#comment-17561624
]
Rhuan Rocha commented on CAMEL-18170:
-
Hi [~davsclaus]
No. I will close this ticket, as the components were updated.
> Add serviceAccountKey parameter to google components
>
>
> Key: CAMEL-18170
> URL: https://issues.apache.org/jira/browse/CAMEL-18170
> Project: Camel
> Issue Type: Improvement
> Components: camel-google-calendar, camel-google-drive,
> camel-google-mail, camel-google-sheets
>Reporter: Claudio Miranda
>Assignee: Otavio Rodolfo Piske
>Priority: Minor
> Fix For: 3.19.0
>
>
> Add support to use {{service account key}} parameter to google components:
> sheets, calendar, mail, drive.
> Similar to google bigquery component.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18255) Memory Leak with default Route and MDC-logging (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561608#comment-17561608
]
Claus Ibsen commented on CAMEL-18255:
-
Thanks for spotting its MDC - MDC is low priority and candidate for deprecation
and removal in the future.
> Memory Leak with default Route and MDC-logging (which includes
> RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.x
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18255) Memory Leak with default Route and MDC-logging (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18255:
Fix Version/s: 3.x
(was: 3.19.0)
> Memory Leak with default Route and MDC-logging (which includes
> RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.x
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18255) Memory Leak with default Route and MDC-logging (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18255:
Priority: Minor (was: Major)
> Memory Leak with default Route and MDC-logging (which includes
> RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.19.0
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18255) Memory Leak with default Route and MDC-logging (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Rambichler updated CAMEL-18255:
---
Summary: Memory Leak with default Route and MDC-logging (which includes
RetryErrorHandler) (was: Memory Leak with default Route (which includes
RetryErrorHandler))
> Memory Leak with default Route and MDC-logging (which includes
> RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
> Fix For: 3.19.0
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Rambichler updated CAMEL-18255:
---
Attachment: screenshot-1.png
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
> Fix For: 3.19.0
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561592#comment-17561592
]
Michael Rambichler commented on CAMEL-18255:
I have added a example project in github:
[https://github.com/michael-salzburg/splitMemoryTest.git]
The issue is the mdc logging:
{color:#FF}camel.springboot.use-mdc-logging=true{color}
Without: Memory Consumption around 100MB. with mdc-logging=true Consumption
goes up till END. GC does not work.
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
> Fix For: 3.19.0
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561567#comment-17561567
]
Claus Ibsen commented on CAMEL-18255:
-
Running as unit test then there is some additonal overhead with the
NotifyBuilder that comes out of the box with camel-core tests, but these
objects are not leaking.
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
> Fix For: 3.19.0
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561562#comment-17561562
]
Claus Ibsen commented on CAMEL-18255:
-
I cannot reproduce any leak with your sample route above. The objects are
allocated but can be GC so you can go down to < 30mb when GC kicks in.
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
> Fix For: 3.19.0
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18255:
Attachment: Screenshot 2022-07-01 at 19.30.44.png
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
> Fix For: 3.19.0
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561555#comment-17561555
]
Claus Ibsen commented on CAMEL-18255:
-
Can you maybe put together this as an unit test or something that is ready to
try so we can more quickly jump on this
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18255:
Fix Version/s: 3.19.0
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
> Fix For: 3.19.0
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18255:
Priority: Major (was: Critical)
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Major
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18252) BridgeExceptionHandlerToErrorHandler with OnCompletion prevents processing Exception
[
https://issues.apache.org/jira/browse/CAMEL-18252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-18252.
-
Resolution: Fixed
> BridgeExceptionHandlerToErrorHandler with OnCompletion prevents processing
> Exception
>
>
> Key: CAMEL-18252
> URL: https://issues.apache.org/jira/browse/CAMEL-18252
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 3.17.0
>Reporter: Benjamin Graf
>Assignee: Benjamin Graf
>Priority: Minor
> Fix For: 3.18.0
>
> Attachments: OnCompletionBridgeErrorHandler.java
>
>
> Using BridgeExceptionHandlerToErrorHandler together with OnCompletion
> prevents to process the Exception because it temporarily gets removed from
> exchange and there is no other reference available. JavaDoc of
> OnCompletionProcessor mentions
> {noformat}
> the caused exception is stored as a property (Exchange.EXCEPTION_CAUGHT) on
> the exchange
> {noformat}
> Might be a possible solution to be set in
> BridgeExceptionHandlerToErrorHandler
> Small test case to verify, see log of missing Exception. (logging null value!)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Rambichler updated CAMEL-18255:
---
Component/s: camel-core
(was: came-core)
> Memory Leak with default Route (which includes RetryErrorHandler)
> -
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Critical
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Then I realized the usage of RetryErrorHandler
>
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator infiniteIter = new Iterator<>() {
> private int integer = 0;
>
> @Override public boolean hasNext() {
> return true;
> }
> @Override public String next() {
> return String.valueOf(integer++);
> }
> };
> exchange.getMessage().setBody(infiniteIter);
> })
> .split().body().streaming()
> .log("inside split: ${body}")
> .end()
> .log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18255) Memory Leak with default Route (which includes RetryErrorHandler)
Michael Rambichler created CAMEL-18255:
--
Summary: Memory Leak with default Route (which includes
RetryErrorHandler)
Key: CAMEL-18255
URL: https://issues.apache.org/jira/browse/CAMEL-18255
Project: Camel
Issue Type: Bug
Components: came-core
Affects Versions: 3.17.0, 3.14.1
Reporter: Michael Rambichler
We realized a sever memory leak in a standard route:
I reproduced it and made a simple MemoryAllocation Check.
Then I realized the usage of RetryErrorHandler
Just for curiosity i made another test with: ({color:#00875a}.errorhandler(no
errorhandler){color}) and the memory leak does not occure.
Sample route to reproduce:
from("scheduler:testScheduler?repeatCount=1")
.log("Starting route test-route")
.process(exchange -> {
Iterator infiniteIter = new Iterator<>() {
private int integer = 0;
@Override public boolean hasNext() {
return true;
}
@Override public String next() {
return String.valueOf(integer++);
}
};
exchange.getMessage().setBody(infiniteIter);
})
.split().body().streaming()
.log("inside split: ${body}")
.end()
.log("test-route never finishes");
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-18252) BridgeExceptionHandlerToErrorHandler with OnCompletion prevents processing Exception
[
https://issues.apache.org/jira/browse/CAMEL-18252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-18252:
---
Assignee: Benjamin Graf
> BridgeExceptionHandlerToErrorHandler with OnCompletion prevents processing
> Exception
>
>
> Key: CAMEL-18252
> URL: https://issues.apache.org/jira/browse/CAMEL-18252
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 3.17.0
>Reporter: Benjamin Graf
>Assignee: Benjamin Graf
>Priority: Minor
> Fix For: 3.18.0
>
> Attachments: OnCompletionBridgeErrorHandler.java
>
>
> Using BridgeExceptionHandlerToErrorHandler together with OnCompletion
> prevents to process the Exception because it temporarily gets removed from
> exchange and there is no other reference available. JavaDoc of
> OnCompletionProcessor mentions
> {noformat}
> the caused exception is stored as a property (Exchange.EXCEPTION_CAUGHT) on
> the exchange
> {noformat}
> Might be a possible solution to be set in
> BridgeExceptionHandlerToErrorHandler
> Small test case to verify, see log of missing Exception. (logging null value!)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18252) BridgeExceptionHandlerToErrorHandler with OnCompletion prevents processing Exception
[
https://issues.apache.org/jira/browse/CAMEL-18252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18252:
Fix Version/s: 3.18.0
> BridgeExceptionHandlerToErrorHandler with OnCompletion prevents processing
> Exception
>
>
> Key: CAMEL-18252
> URL: https://issues.apache.org/jira/browse/CAMEL-18252
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 3.17.0
>Reporter: Benjamin Graf
>Priority: Minor
> Fix For: 3.18.0
>
> Attachments: OnCompletionBridgeErrorHandler.java
>
>
> Using BridgeExceptionHandlerToErrorHandler together with OnCompletion
> prevents to process the Exception because it temporarily gets removed from
> exchange and there is no other reference available. JavaDoc of
> OnCompletionProcessor mentions
> {noformat}
> the caused exception is stored as a property (Exchange.EXCEPTION_CAUGHT) on
> the exchange
> {noformat}
> Might be a possible solution to be set in
> BridgeExceptionHandlerToErrorHandler
> Small test case to verify, see log of missing Exception. (logging null value!)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18253) camel-kafka: idempotent repository may report incorrect number of messages
[ https://issues.apache.org/jira/browse/CAMEL-18253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18253. - Resolution: Fixed > camel-kafka: idempotent repository may report incorrect number of messages > -- > > Key: CAMEL-18253 > URL: https://issues.apache.org/jira/browse/CAMEL-18253 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.14.4, 3.17.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Minor > Fix For: 3.14.5, 3.18.0 > > > Any code that calls the (potentially) safe contains method on the Kafka > idempotent repository may cause it to incorrectly report an additional number > of duplicate messages because it uses incrementAndGet on the counter: > > https://github.com/apache/camel/blob/camel-3.17.x/components/camel-kafka/src/main/java/org/apache/camel/processor/idempotent/kafka/KafkaIdempotentRepository.java#L375-L382 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18254) camel-jbang - Kamelets should only log explicit configured options on startup
[ https://issues.apache.org/jira/browse/CAMEL-18254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18254: Summary: camel-jbang - Kamelets should only log explicit configured options on startup (was: camel-jbang - Kamelets log their option on startup) > camel-jbang - Kamelets should only log explicit configured options on startup > - > > Key: CAMEL-18254 > URL: https://issues.apache.org/jira/browse/CAMEL-18254 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.19.0 > > > We should look at making kamelets not log their default options, as that is a > bit noisy. > For example running > camel-kamelets-examples/jbang/metrics main *1 ❯ camel run metrics.yaml > --console > You see > 2022-07-01 12:57:44.883 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: Property-placeholders summary > 2022-07-01 12:57:44.883 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] > period=1000 > 2022-07-01 12:57:44.884 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] > message=hello > 2022-07-01 12:57:44.884 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] > contentType=text/plain > 2022-07-01 12:57:44.884 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] > templateId=timer-source > The only specific option we use in this example is message=hello. The other > values are default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18254) camel-jbang - Kamelets log their option on startup
[ https://issues.apache.org/jira/browse/CAMEL-18254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561416#comment-17561416 ] Claus Ibsen commented on CAMEL-18254: - Also the source seems wrong as its metrics.yaml that set this via uri: kamelet:timer-source?message=hello > camel-jbang - Kamelets log their option on startup > -- > > Key: CAMEL-18254 > URL: https://issues.apache.org/jira/browse/CAMEL-18254 > Project: Camel > Issue Type: Improvement > Components: camel-jbang >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.19.0 > > > We should look at making kamelets not log their default options, as that is a > bit noisy. > For example running > camel-kamelets-examples/jbang/metrics main *1 ❯ camel run metrics.yaml > --console > You see > 2022-07-01 12:57:44.883 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: Property-placeholders summary > 2022-07-01 12:57:44.883 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] > period=1000 > 2022-07-01 12:57:44.884 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] > message=hello > 2022-07-01 12:57:44.884 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] > contentType=text/plain > 2022-07-01 12:57:44.884 INFO 54705 --- [ main] > org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] > templateId=timer-source > The only specific option we use in this example is message=hello. The other > values are default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18254) camel-jbang - Kamelets log their option on startup
Claus Ibsen created CAMEL-18254: --- Summary: camel-jbang - Kamelets log their option on startup Key: CAMEL-18254 URL: https://issues.apache.org/jira/browse/CAMEL-18254 Project: Camel Issue Type: Improvement Components: camel-jbang Reporter: Claus Ibsen Fix For: 3.19.0 We should look at making kamelets not log their default options, as that is a bit noisy. For example running camel-kamelets-examples/jbang/metrics main *1 ❯ camel run metrics.yaml --console You see 2022-07-01 12:57:44.883 INFO 54705 --- [ main] org.apache.camel.main.BaseMainSupport: Property-placeholders summary 2022-07-01 12:57:44.883 INFO 54705 --- [ main] org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] period=1000 2022-07-01 12:57:44.884 INFO 54705 --- [ main] org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] message=hello 2022-07-01 12:57:44.884 INFO 54705 --- [ main] org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] contentType=text/plain 2022-07-01 12:57:44.884 INFO 54705 --- [ main] org.apache.camel.main.BaseMainSupport: [timer-source.kamelet.yaml] templateId=timer-source The only specific option we use in this example is message=hello. The other values are default values. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18250) When a Call to Salesforce timeouts then we have Exchange.HTTP_RESPONSE_CODE Exchange Header set as "0"
[ https://issues.apache.org/jira/browse/CAMEL-18250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18250: Affects Version/s: 3.14.4 > When a Call to Salesforce timeouts then we have Exchange.HTTP_RESPONSE_CODE > Exchange Header set as "0" > -- > > Key: CAMEL-18250 > URL: https://issues.apache.org/jira/browse/CAMEL-18250 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.14.4, 3.17.0 >Reporter: Babak Vahdat >Assignee: Babak Vahdat >Priority: Minor > Fix For: 3.14.5, 3.18.0 > > > As because then there is an implicit 0 (as int) to "0" (as string) conversion > happening. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18250) When a Call to Salesforce timeouts then we have Exchange.HTTP_RESPONSE_CODE Exchange Header set as "0"
[ https://issues.apache.org/jira/browse/CAMEL-18250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18250: Fix Version/s: 3.14.5 > When a Call to Salesforce timeouts then we have Exchange.HTTP_RESPONSE_CODE > Exchange Header set as "0" > -- > > Key: CAMEL-18250 > URL: https://issues.apache.org/jira/browse/CAMEL-18250 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.17.0 >Reporter: Babak Vahdat >Assignee: Babak Vahdat >Priority: Minor > Fix For: 3.14.5, 3.18.0 > > > As because then there is an implicit 0 (as int) to "0" (as string) conversion > happening. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18253) camel-kafka: idempotent repository may report incorrect number of messages
[ https://issues.apache.org/jira/browse/CAMEL-18253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561413#comment-17561413 ] Otavio Rodolfo Piske commented on CAMEL-18253: -- Yes I can. I am working on it. > camel-kafka: idempotent repository may report incorrect number of messages > -- > > Key: CAMEL-18253 > URL: https://issues.apache.org/jira/browse/CAMEL-18253 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.14.4, 3.17.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Minor > Fix For: 3.14.5, 3.18.0 > > > Any code that calls the (potentially) safe contains method on the Kafka > idempotent repository may cause it to incorrectly report an additional number > of duplicate messages because it uses incrementAndGet on the counter: > > https://github.com/apache/camel/blob/camel-3.17.x/components/camel-kafka/src/main/java/org/apache/camel/processor/idempotent/kafka/KafkaIdempotentRepository.java#L375-L382 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18253) camel-kafka: idempotent repository may report incorrect number of messages
[ https://issues.apache.org/jira/browse/CAMEL-18253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561412#comment-17561412 ] Claus Ibsen commented on CAMEL-18253: - Can you backport to 3.14.x branch > camel-kafka: idempotent repository may report incorrect number of messages > -- > > Key: CAMEL-18253 > URL: https://issues.apache.org/jira/browse/CAMEL-18253 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.14.4, 3.17.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Minor > Fix For: 3.18.0 > > > Any code that calls the (potentially) safe contains method on the Kafka > idempotent repository may cause it to incorrectly report an additional number > of duplicate messages because it uses incrementAndGet on the counter: > > https://github.com/apache/camel/blob/camel-3.17.x/components/camel-kafka/src/main/java/org/apache/camel/processor/idempotent/kafka/KafkaIdempotentRepository.java#L375-L382 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18253) camel-kafka: idempotent repository may report incorrect number of messages
[ https://issues.apache.org/jira/browse/CAMEL-18253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18253: Fix Version/s: 3.14.5 > camel-kafka: idempotent repository may report incorrect number of messages > -- > > Key: CAMEL-18253 > URL: https://issues.apache.org/jira/browse/CAMEL-18253 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.14.4, 3.17.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Minor > Fix For: 3.14.5, 3.18.0 > > > Any code that calls the (potentially) safe contains method on the Kafka > idempotent repository may cause it to incorrectly report an additional number > of duplicate messages because it uses incrementAndGet on the counter: > > https://github.com/apache/camel/blob/camel-3.17.x/components/camel-kafka/src/main/java/org/apache/camel/processor/idempotent/kafka/KafkaIdempotentRepository.java#L375-L382 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18253) camel-kafka: idempotent repository may report incorrect number of messages
[ https://issues.apache.org/jira/browse/CAMEL-18253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18253: Fix Version/s: 3.18.0 > camel-kafka: idempotent repository may report incorrect number of messages > -- > > Key: CAMEL-18253 > URL: https://issues.apache.org/jira/browse/CAMEL-18253 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.14.4, 3.17.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Minor > Fix For: 3.18.0 > > > Any code that calls the (potentially) safe contains method on the Kafka > idempotent repository may cause it to incorrectly report an additional number > of duplicate messages because it uses incrementAndGet on the counter: > > https://github.com/apache/camel/blob/camel-3.17.x/components/camel-kafka/src/main/java/org/apache/camel/processor/idempotent/kafka/KafkaIdempotentRepository.java#L375-L382 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18253) camel-kafka: idempotent repository may report incorrect number of messages
[ https://issues.apache.org/jira/browse/CAMEL-18253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-18253: - Issue Type: Bug (was: Task) > camel-kafka: idempotent repository may report incorrect number of messages > -- > > Key: CAMEL-18253 > URL: https://issues.apache.org/jira/browse/CAMEL-18253 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.14.4, 3.17.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > > Any code that calls the (potentially) safe contains method on the Kafka > idempotent repository may cause it to incorrectly report an additional number > of duplicate messages because it uses incrementAndGet on the counter: > > https://github.com/apache/camel/blob/camel-3.17.x/components/camel-kafka/src/main/java/org/apache/camel/processor/idempotent/kafka/KafkaIdempotentRepository.java#L375-L382 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18253) camel-kafka: idempotent repository may report incorrect number of messages
[ https://issues.apache.org/jira/browse/CAMEL-18253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-18253: - Priority: Minor (was: Major) > camel-kafka: idempotent repository may report incorrect number of messages > -- > > Key: CAMEL-18253 > URL: https://issues.apache.org/jira/browse/CAMEL-18253 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.14.4, 3.17.0 >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Minor > > Any code that calls the (potentially) safe contains method on the Kafka > idempotent repository may cause it to incorrectly report an additional number > of duplicate messages because it uses incrementAndGet on the counter: > > https://github.com/apache/camel/blob/camel-3.17.x/components/camel-kafka/src/main/java/org/apache/camel/processor/idempotent/kafka/KafkaIdempotentRepository.java#L375-L382 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18250) When a Call to Salesforce timeouts then we have Exchange.HTTP_RESPONSE_CODE Exchange Header set as "0"
[ https://issues.apache.org/jira/browse/CAMEL-18250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18250. - Resolution: Fixed > When a Call to Salesforce timeouts then we have Exchange.HTTP_RESPONSE_CODE > Exchange Header set as "0" > -- > > Key: CAMEL-18250 > URL: https://issues.apache.org/jira/browse/CAMEL-18250 > Project: Camel > Issue Type: Bug > Components: camel-salesforce >Affects Versions: 3.17.0 >Reporter: Babak Vahdat >Assignee: Babak Vahdat >Priority: Minor > Fix For: 3.18.0 > > > As because then there is an implicit 0 (as int) to "0" (as string) conversion > happening. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18246) CVE-2022-26612: Upgrade hadoop-common >= 2.10.2, 3.3.3
[ https://issues.apache.org/jira/browse/CAMEL-18246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18246: Fix Version/s: 3.18.1 3.19.0 (was: 3.18.0) > CVE-2022-26612: Upgrade hadoop-common >= 2.10.2, 3.3.3 > -- > > Key: CAMEL-18246 > URL: https://issues.apache.org/jira/browse/CAMEL-18246 > Project: Camel > Issue Type: Dependency upgrade >Reporter: Alex Dettinger >Assignee: Alex Dettinger >Priority: Major > Fix For: 3.19.0, 3.18.1 > > > It relates to > [CAMEL-QUAKRUS-3763|https://github.com/apache/camel-quarkus/issues/3763] > where hbase and hdfs are affected by > |CVE-2022-26612|https://nvd.nist.gov/vuln/detail/CVE-2022-26612]. > According to HADOOP-18155, we need to upgrade to > org.apache.hadoop:hadoop-common >= 2.10.2, 3.2.3, 3.3.3, 3.4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18253) camel-kafka: idempotent repository may report incorrect number of messages
Otavio Rodolfo Piske created CAMEL-18253: Summary: camel-kafka: idempotent repository may report incorrect number of messages Key: CAMEL-18253 URL: https://issues.apache.org/jira/browse/CAMEL-18253 Project: Camel Issue Type: Task Components: camel-kafka Affects Versions: 3.17.0, 3.14.4 Reporter: Otavio Rodolfo Piske Assignee: Otavio Rodolfo Piske Any code that calls the (potentially) safe contains method on the Kafka idempotent repository may cause it to incorrectly report an additional number of duplicate messages because it uses incrementAndGet on the counter: https://github.com/apache/camel/blob/camel-3.17.x/components/camel-kafka/src/main/java/org/apache/camel/processor/idempotent/kafka/KafkaIdempotentRepository.java#L375-L382 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18246) CVE-2022-26612: Upgrade hadoop-common >= 2.10.2, 3.3.3
[ https://issues.apache.org/jira/browse/CAMEL-18246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561332#comment-17561332 ] Alex Dettinger commented on CAMEL-18246: Ok, we finally reverted everything as some itests were broken in CI. Let's retake this step by step after the release. > CVE-2022-26612: Upgrade hadoop-common >= 2.10.2, 3.3.3 > -- > > Key: CAMEL-18246 > URL: https://issues.apache.org/jira/browse/CAMEL-18246 > Project: Camel > Issue Type: Dependency upgrade >Reporter: Alex Dettinger >Assignee: Alex Dettinger >Priority: Major > Fix For: 3.18.0 > > > It relates to > [CAMEL-QUAKRUS-3763|https://github.com/apache/camel-quarkus/issues/3763] > where hbase and hdfs are affected by > |CVE-2022-26612|https://nvd.nist.gov/vuln/detail/CVE-2022-26612]. > According to HADOOP-18155, we need to upgrade to > org.apache.hadoop:hadoop-common >= 2.10.2, 3.2.3, 3.3.3, 3.4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18252) BridgeExceptionHandlerToErrorHandler with OnCompletion prevents processing Exception
Benjamin Graf created CAMEL-18252:
-
Summary: BridgeExceptionHandlerToErrorHandler with OnCompletion
prevents processing Exception
Key: CAMEL-18252
URL: https://issues.apache.org/jira/browse/CAMEL-18252
Project: Camel
Issue Type: Bug
Components: came-core
Affects Versions: 3.17.0
Reporter: Benjamin Graf
Attachments: OnCompletionBridgeErrorHandler.java
Using BridgeExceptionHandlerToErrorHandler together with OnCompletion prevents
to process the Exception because it temporarily gets removed from exchange and
there is no other reference available. JavaDoc of OnCompletionProcessor mentions
{noformat}
the caused exception is stored as a property (Exchange.EXCEPTION_CAUGHT) on the
exchange
{noformat}
Might be a possible solution to be set in BridgeExceptionHandlerToErrorHandler
Small test case to verify, see log of missing Exception. (logging null value!)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
