[
https://issues.apache.org/jira/browse/CAMEL-22691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18038851#comment-18038851
]
Lars Haugaard Kristensen commented on CAMEL-22691:
--------------------------------------------------
I have tested the fix with 4.16.0 using the reproducer project only, as I'm
unable to upgrade my actual application to 4.16.0 without considerable effort.
There seems to have been no changes to {{CxfProducer}} since CAMEL-21302 (Fix
versions: 4.4.5, 4.8.2, 4.9.0).
> 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)
