Undertow Keeps Sockets in CLOSE_WAIT for 2 Minutes After Client Disconnect
Nguyễn Toàn
We are encountering a persistent socket state issue in WildFly 26/31 involving the Undertow web server. Specifically, after an HTTP client closes its connection, the corresponding server-side socket remains in the CLOSE_WAIT state for approximately 2 minutes. This behavior is reproducible under normal load and occurs even when the client has properly terminated the connection.
From our investigation, it appears that Undertow does not immediately close its end of the socket, which leads to a buildup of sockets in CLOSE_WAIT. This can cause resource exhaustion under high traffic conditions. We have verified that the client is not keeping the connection open and that the server receives the TCP FIN signal, yet the socket remains open on the server side until the timeout expires.
We attempted to mitigate this by tuning Undertow settings, such as disabling tcp-keep-alive, but the CLOSE_WAIT duration remains close to 2 minutes. Additionally, we found that WildFly does not expose low-level socket options like SO_LINGER in the Undertow subsystem configuration, which limits our ability to force immediate socket closure.
We would like to understand:
Whether this behavior is expected in Undertow’s default configuration.
If there are any supported configuration options to reduce the CLOSE_WAIT linger time.
Whether this can be addressed in future releases or via custom extensions.
Please advise on best practices or configuration changes that can help resolve or mitigate this issue.
[ser ~]# date;netstat -na | grep 8080
tcp6 0 0 :::8080 :::* LISTEN
tcp6 0 0 192.168.92.19:8080 192.168.107.7:57506 ESTABLISHED
[ser ~]# date;netstat -na | grep 8080
Tue Oct 28 11:32:45 +07 2025
tcp6 0 0 :::8080 :::* LISTEN
tcp6 81 0 192.168.92.19:8080 192.168.107.7:57506 CLOSE_WAIT
[ser ~]# date;netstat -na | grep 8080
Tue Oct 28 11:34:43 +07 2025
tcp6 0 0 :::8080 :::* LISTEN
tcp6 81 0 192.168.92.19:8080 192.168.107.7:57506 CLOSE_WAIT
[ser ~]# date;netstat -na | grep 8080
Tue Oct 28 11:34:44 +07 2025
tcp6 0 0 :::8080 :::* LISTEN
Bartosz Baranowski
https://wildfly.zulipchat.com/#narrow/channel/174183-undertow/topic/.E2.9C.94.20Connections.20Stuck.20in.20CLOSE_WAIT/with/522770430
https://lists.jboss.org/archives/list/undert...@lists.jboss.org/thread/I5APAEZDAQSHMIIFAJ6EVTX7KG2KOVLX/ --> https://github.com/xnio/xnio/blob/3.x/api/src/main/java/org/xnio/Options.java
Though brief overlook of socket channels and XNIO its a bit puzzling outcome, as https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/nio/channels/ServerSocketChannel.html - whcih seems to be backed by: https://github.com/xnio/xnio/blob/3.x/nio-impl/src/main/java/org/xnio/nio/WorkerThread.java#L117 - SO_LINGER is not supported?
In original thread user wasnt able to reproduce at will - if you can, it would be great to turn this into reproducer.