On the Wildfly 10 CR1 - CR4 releases we were able to keep an Apache HTTP Client connection pool to Wildfly open. On the CR5 release we see connections that are hanging (java.net.SocketInputStream.socketRead0 on the client side).

I diagnosed this problem with building a small Java program that creates a connection pool, spawns 1 thread and tries to execute an endpoint on the Wildfly server. It keeps doing this forever, over 1 connection with keep-alive enabled. I tried to run this on CR1 - C5, like previously stated CR1 - CR4 work fine, CR5 results in a hanging connection.

In my testing this has always happened in the first 100.000 HTTP requests. This does not happen at the same time interval, or request count. I've been playing with the Wildfly undertow parameters, but this did not seem to make a difference.

I downgraded the bundled undertow-core dependency in the CR5 release of Wildfly 10 to 1.3.3.Final and went up from there. For 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.3.8, 1.3.9. and 1.3.10 all seem to work fine. When I try 1.3.11 the pool freezes after a while. All threads keep hanging on (socketRead0). Upgrading to 1.3.12.Final does not resolve this issue.

I checked out the undertow source code, and tried to find the commit that breaks the connection pool. It seems that commit "8c8e16c780a9e735ea9f90dadf1e08adb7fdb8a0" introduces this error. When I rebase the master branch and remove this commit from history, I no longer see hanging connections. When I build commit "eb1ca6b249ba89b374517940a25d93ec359c162a" manually (which is the parent of the previously stated commit), the test program won't hang. To me this means that commit "8c8e16c" introduced this bug.

When inspecting the code, I have the feeling that the commit does what it describes to do, and I do not know how it could introduce hanging connections.

For me it would be a shame if the final version of Wildfly 10 would be released with a undertow-core version that makes using a HTTP connection pool impossible.