Andrey created CXF-9100:
---------------------------
Summary: HttpClient-1-Worker-* thread leak when throwing exception
in LoggingOutInterceptor and sending large SOAP message
Key: CXF-9100
URL: https://issues.apache.org/jira/browse/CXF-9100
Project: CXF
Issue Type: Bug
Components: logging, Transports
Affects Versions: 3.6.5, 4.1.0, 4.0.4
Reporter: Andrey
Attachments: image-2025-01-13-12-39-07-688.png,
image-2025-01-13-12-40-36-534.png
Hello,
After upgrading from 3.5.3 to 3.6+ (tried 3.6.5, 4.0.4, 4.1.0) we have noticed
a HttpClient-1-Worker-* thread leak. Screenshots from VisualVM in attachments.
How to reproduce:
# register custom LogEventSender and LoggingOutInterceptor
# throw any exception in send() method
# send SOAP message with body >4kb (default chunkingThreshold value for
HTTPConduit)
# repeat previous step N times
# watch HttpClient-1-Worker-* threads count grow till
RejectedExecutionException for JDK17 or OutOfMemoryError for JDK21 after 3984
(in my case) threads
Possible workaround:
Configure chunkingThreshold with greater value
Example for Spring:
{code:java}
@Bean
fun httpConduitConfigurer(): HTTPConduitConfigurer {
return HTTPConduitConfigurer { _, _, conduit ->
val httpClientPolicy = HTTPClientPolicy()
httpClientPolicy.chunkingThreshold = 16384
conduit.setClient(httpClientPolicy)
}
} {code}
I wrote a demo project for this case:
https://github.com/AndChelp/cxf-thread-leak
You can run TestControllerTest#testCommonEndpoint and watch «HttpClient-1-*
thread count: N» log. Or you can run it as Spring Application, send GET /common
request and watch threads with any profiler.
The project also has a configured workaround on /workaround endpoint and test
for it
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
