[
https://issues.apache.org/jira/browse/CAMEL-22691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-22691.
---------------------------------
Resolution: Fixed
> 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
> Fix For: 4.10.8, 4.14.3, 4.17.0
>
> 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)
