[
https://issues.apache.org/jira/browse/CAMEL-22691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18038664#comment-18038664
]
Lars Haugaard Kristensen commented on CAMEL-22691:
--------------------------------------------------
I have a proposed fix:
[https://github.com/Larshk/camel/commit/fe4da627c14efb311d1775054e11f0f89fb02a9b]
It's based on {{{}camel-4.10.x{}}}. Both synchronouos and asynchronous
producers are addressed. It works by ensuring that request and response
contexts are cleared for the current thread when no longer needed.
I tested it with the reproducer as well as my own application.
My worry is introducing a regression because of my limited experience with the
codebase.
Let me know if I should open a PR.
Would it be OK to target {{{}camel-4.10.x{}}}?
> camel-cxf - Memory leak in CXF producer
> ---------------------------------------
>
> Key: CAMEL-22691
> URL: https://issues.apache.org/jira/browse/CAMEL-22691
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
> Affects Versions: 4.10.7, 4.14.2, 4.16.0
> Environment: Camel Spring Boot 4.10.3
> Red Hat OpenJDK 17
> REST component is "platform-http"
> Embedded web server is Tomcat
> OS is RHEL 8.10
> Reporter: Lars Haugaard Kristensen
> Priority: Major
> Attachments: cxf-leak-jprofiler.png
>
>
> Zulip topic: [#camel > Memory leak in CXF
> client|https://camel.zulipchat.com/#narrow/channel/257298-camel/topic/Memory.20leak.20in.20CXF.20client/with/555530583]
> I'm seeing a memory leak in a production system, leading to OOM. The
> application is based on Spring Boot, Tomcat, and platform-http as the rest
> component.
> I use a REST consumer that performs some mapping, then calls a SOAP service
> using CXF. Internally in CXF, a map from Thread to responseContext is not
> cleaned up when the exchange completes, and the map simply grows, and entries
> are not garbage collected (ref.
> org.apache.cxf.endpoint.ClientImpl#responseContext).
> I have put together a reproducer which is available on Github:
> [https://github.com/Larshk/camel-cxf-leak]
> The behavior can be reproduced in Camel versions 4.10.7, 4.14.2, and 4.16.0.
> I can work around the problem by setting the following property, which is not
> ideal:
> {{spring.task.execution.pool.allow-core-thread-timeout=false}}
> I found this (old) CXF issue which seems somewhat related:
> https://issues.apache.org/jira/browse/CXF-7710
> By debugging I see that org.apache.cxf.endpoint.ClientImpl#setResponseContext
> is called on two separate threads during the exchange processing, such as:
> {noformat}
> Response context set on thread task-1, responseContext.size() after: 13
> Response context set on thread default-workqueue-4, responseContext.size()
> after: 13
> Response context set on thread default-workqueue-4, responseContext.size()
> after: 13
> {noformat}
> In this case the "task-1" thread is created by an executor of type:
> {{org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor}}
> This executor is by default configured to un-alive idle core threads. When
> there is low activity, threads are terminated and new are created when
> needed, leading to new entries in the responseContext map.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
