Spring-Framework Build Stalls During WebFlux Tests with Reactor Netty Timeout

[Due-IT]

Repeated attempts to build the spring-framework project are consistently stalling (hanging indefinitely) at a specific point during test execution. The build does not complete successfully.
It used jdk25

The issue is strongly suspected to be isolated to the spring-webflux module, specifically during tests spring-webflux/../MultipartWebClientIntegrationTests/requestBodyMap utilize Reactor Netty.

Detailed Analysis and Findings

1. Issue On Reactor Netty Environment

When running webflux tests separately, a infinite loading was identified:

This confirms the issue is within the spring-webflux tests involving Reactor Netty, leading to an unreceived response/infinite wait.

2. Basic Server/Connection Checks

netstat confirmed the necessary port (e.g., 49827) was open, indicating the server started successfully.

Basic TCP connection tests were also successful.

3. Thread Dump Analysis (Client Side)

Debugging the tests ./gradlew test --info --debug and taking a thread dump of the client-side test process (PID: 24560) revealed:

• Client threads were perpetually waiting for results from Reactor, indicating they were stuck waiting for an unfulfilled promise/resource, though not a classical deadlock.
• The Reactor Event Loop threads (handling I/O) appeared to be in a normal idle state.

4. Thread Dump Analysis (Server Side)

Taking a thread dump of the server-side process (PID: 2640), which includes reactor-http-nio threads, and analyzing it showed:

• The majority of application request processing threads (org.eclipse.jetty.util.thread.QueuedThreadPool$Runner family) were in WAITING or TIMED_WAITING states.
• This was initially suspected to be due to increased system load from the thread count or prolonged Stop-The-World (STW) GC pauses. (However, upon analysis using JConsole, there appeared to be no issues with GC, memory, CPU overload, or deadlocks.)

thread_dump1.txt
thread_dump2.txt
thread_dump3.txt

Futhermore, problem persisted even after changing Wi-Fi networks or using a hotspot.

[bclozel]

Thanks for getting in touch, but we don't have the time to debug your setup. We would very much like for you to contribute, but we cannot reproduce this at the moment.
Our CI runs smoothly and I don't remember this happening consistently in my local setup. Network glitches and races do happen from time to time in integration tests but never so reliably.

I can only suggest to turn off local security software that intercepts network traffic. Those tend to cause issues like this.

Thanks

[Due-IT]

I see. If I get the chance to contribute, I'll make sure to implement and test it without using WebFlux. :)