Hello,
I have a suspicion on (or better I faced to) memory leak in the following
situation. I use HttpProducer endpoint with "unlimited" redelivery
(configuration problem), but the problem is present for "limited" redelivery
too. Here is simplified route, which I used for problem simulation (finally
I got OOM in this simulation):
return new RouteBuilder() {
public void configure() {
errorHandler(
defaultErrorHandler().maximumRedeliveries(-1).redeliveryDelay(5).maximumRedeliveryDelay(5)
);
from("direct:start").setHeader(Exchange.HTTP_METHOD,
POST).to("http://localhost:8899/test";);
}
};
The problem occurs, when HTTP server returns 404 as response code (for
example when the target "web application" is undeployed from web application
container). In this situation the next/new "synchronization" callback is
registered in each HttpProducer endpoint processing, which caused that we
have a lot of "close" synchronization actions registered on UnitOfWork in
some time (OOM problem in extreme situation) - see
org.apache.camel.converter.stream.CachedOutputStream(Exchange exchange,
final boolean closedOnCompletion, which is invoked from HttpProducer, method
doExtractResponseBodyAsStream(...))
Maybe the problem relates to CAMEL-7055, where the synchronization callback
is registered even if closedOnCompletion parameter is false.
I see, that "stream close synchronization" is necessary, mainly for
situation, where we got the valid body response, but maybe for
"populateHttpOperationFailedException" isn't necessary to register the
synchronization action at all, because the response body is only converted
into java.lang.String.
I would like to ask, if my solution with using redelivery, is based on wrong
idea or I discovered a bug, which should be reported to JIRA.
Thank you for any feedback.
Radek Kraus.
--
View this message in context:
http://camel.465427.n5.nabble.com/HttpProducer-endpoint-with-unlimited-limited-redelivery-memory-leak-tp5760285.html
Sent from the Camel - Users mailing list archive at Nabble.com.
