On Tue, 3 Nov 2026 08:20:16 GMT, Jaikiran Pai <[email protected]> wrote:
>> Volkan Yazici has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains nine commits:
>>
>> - Merge remote-tracking branch 'upstream/master' into hsProp
>> - Add `Host` headers
>> - Merge remote-tracking branch 'upstream/master' into hsProp
>> - Merge remote-tracking branch 'upstream/master' into hsProp
>> - Apply review feedback from
>> - Merge remote-tracking branch 'upstream/master' into hsProp
>> - Delete `DrainAmountPropertyTest`, it will be delivered with 8387853
>> - Merge remote-tracking branch 'upstream/master' into hsProp
>> - Add tests for `HttpServer` configuration system properties
>
> test/jdk/com/sun/net/httpserver/property/MaxConnectionsPropertyTest.java line
> 132:
>
>> 130: // `assertThrows` expects `SocketException`
>> to verify disconnect.
>> 131: // Use `SocketException` to signal EOF.
>> 132: throw new SocketException("EOF");
>
> Hello Volkan, I don't fully follow this assertThrows call. Should the
> `assertThrows` only wrap the `connectAndWriteRequest()` call? The
> `connectAndWriteRequest()` does a new `connect()` and then writes to the
> socket. Are you seeing a case where the connect followed by the write
> succeeds without any exception even when the connection limit imposed by the
> server is reached?
Yes, almost every time. You can comment out the `if` block at line 129 and
observe the test failure yourself locally.
`connectAndWriteRequest()` succeeding means the connection is established and
the socket is accepted. The server checks the limit after `accept()`.
Meanwhile, the client can complete the data delivery. Neither `flush()` waits
for the server to read and process the bytes. The only way to ensure the
request rejection is to read the disconnect issued by the server, hence the
`read() == -1`.
Does this answer your question?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31974#discussion_r4452730276
