RFR: 8330940: Impossible to create a socket backlog greater than 200 on Windows 8+ [v2]

Jaikiran Pai jpai at openjdk.org
Fri Jun 27 12:42:47 UTC 2025


On Tue, 17 Jun 2025 09:26:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/ServerSocket/LargeBacklogTest.java line 96:
>> 
>>> 94:                 // do not attempt any more connections
>>> 95:                 break;
>>> 96:             }
>> 
>> hmm... interesting: so we don't need to leave the socket open to increase the backlog. I guess the server side has to accept the socket and read the FIN, so the backlog won't be decremented until the socket is accepted (even if it's already closed on the client side).
>
> That's a good question. The current behaviour (on Windows and *nix) is that, closing the Socket which initiated the connection doesn't affect the number of connections that were put into a pending queue (backlog) on the server side. I will need to read up a bit to see if that is specified or if it is merely an implementation detail.

> hmm... interesting: so we don't need to leave the socket open to increase the backlog. I guess the server side has to accept the socket and read the FIN, so the backlog won't be decremented until the socket is accepted (even if it's already closed on the client side).

I couldn't find this specified anywhere, but I went through the Linux source code. In that implementation, the backlog is used to size the accept queue. When a connection is made by a client, the count is incremented and tracked against the backlog value. When a connection is `accept()` that count is decremented. So unless the server `accept()`s a connection, the counter keeps increasing and thus hitting the backlog limit. This behaviour matches what's being done in this test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25819#discussion_r2171963956


More information about the net-dev mailing list