[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=17561953#comment-17561953
]
Rhuan Rocha commented on CAMEL-18093:
-
Hi [~davsclaus],
I`m working on camel-http, but I have noted you provided an example using rest.
I`ll apply to both components, 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-18255) Memory Leak with MDCUnitOfWork
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561919#comment-17561919
]
Michael Rambichler edited comment on CAMEL-18255 at 7/3/22 6:25 PM:
Hi [~davsclaus]
The issue is quite independent of MDC.
See my example in [https://github.com/michael-salzburg/splitMemoryTest.git]
I spend some time to analyse it further:
If you override the method of the DefaultUnitOfWork or MDCUnitOfWork and return
{color:#de350b}true{color}: Then the Memory Leak occurs.
@Override
public boolean isBeforeAfterProcess() {
{color:#de350b}return true; //like its set e.g. in MDCUnitOfWork{color}
}
The current MDCUnitOfWork returns true in this case.
But i wasn't able to analyse the impact in deep of this change, yet.
Btw. You mentioned MDC is low prio/candidate for dprecation: We use MDC logging
of especially the breadcrumbId heavily in our system. That would have major
impact in our environment.
was (Author: rambichler):
Hi [~davsclaus]
The issue is quite independent of MDC.
See my example in [https://github.com/michael-salzburg/splitMemoryTest.git]
I spend some time to analyse it further:
If you override the method of the DefaultUnitOfWork or MDCUnitOfWork and return
{color:#de350b}true{color}: Then the Memory Leak occurs. (Event the
@Override
public boolean isBeforeAfterProcess() {
{color:#de350b}return true; //like its set e.g. in MDCUnitOfWork{color}
}
The current MDCUnitOfWork returns true in this case.
But i wasn't able to analyse the impact in deep of this change, yet.
Btw. You mentioned MDC is low prio/candidate for dprecation: We use MDC logging
of especially the breadcrumbId heavily in our system. That would have major
impact in our environment.
> Memory Leak with MDCUnitOfWork
> --
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.x
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator 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 MDCUnitOfWork
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17561919#comment-17561919
]
Michael Rambichler commented on CAMEL-18255:
Hi [~davsclaus]
The issue is quite independent of MDC.
See my example in [https://github.com/michael-salzburg/splitMemoryTest.git]
I spend some time to analyse it further:
If you override the method of the DefaultUnitOfWork or MDCUnitOfWork and return
{color:#de350b}true{color}: Then the Memory Leak occurs. (Event the
@Override
public boolean isBeforeAfterProcess() {
{color:#de350b}return true; //like its set e.g. in MDCUnitOfWork{color}
}
The current MDCUnitOfWork returns true in this case.
But i wasn't able to analyse the impact in deep of this change, yet.
Btw. You mentioned MDC is low prio/candidate for dprecation: We use MDC logging
of especially the breadcrumbId heavily in our system. That would have major
impact in our environment.
> Memory Leak with MDCUnitOfWork
> --
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.x
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator 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 MDCUnitOfWork
[
https://issues.apache.org/jira/browse/CAMEL-18255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Rambichler updated CAMEL-18255:
---
Description:
We realized a sever memory leak in a standard route:
I reproduced it and made a simple MemoryAllocation Check.
Just for curiosity i made another test with: ({color:#00875a}.errorhandler(no
errorhandler){color}) and the memory leak does not occure.
Sample route to reproduce:
from("scheduler:testScheduler?repeatCount=1")
.log("Starting route test-route")
.process(exchange -> {
Iterator 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");
was:
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");
> Memory Leak with MDCUnitOfWork
> --
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.x
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> Just for curiosity i made another test with:
> ({color:#00875a}.errorhandler(no errorhandler){color}) and the memory leak
> does not occure.
>
> Sample route to reproduce:
>
> from("scheduler:testScheduler?repeatCount=1")
> .log("Starting route test-route")
> .process(exchange -> {
> Iterator 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 MDCUnitOfWork
[
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 MDCUnitOfWork (was: Memory Leak with default
Route and MDC-logging (which includes RetryErrorHandler))
> Memory Leak with MDCUnitOfWork
> --
>
> Key: CAMEL-18255
> URL: https://issues.apache.org/jira/browse/CAMEL-18255
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.14.1, 3.17.0
>Reporter: Michael Rambichler
>Priority: Minor
> Fix For: 3.x
>
> Attachments: Screenshot 2022-07-01 at 19.30.44.png, screenshot-1.png
>
>
> We realized a sever memory leak in a standard route:
>
> I reproduced it and made a simple MemoryAllocation Check.
> 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)
