On Mon, 13 Apr 2026 12:02:10 GMT, Arno Zeller <[email protected]> wrote:
>> Matthew Donovan has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>> commits since the last revision:
>>
>> - updated test to enable server thread to exit quickly if client has
>> connection error
>> - Merge branch 'master' into disable-cipher-suites
>> - 8374454: Test
>> sun/security/ssl/CipherSuite/DisabledCipherSuitesNotNegotiated.java from
>> JDK-8356544 shows intermittent timeouts
>
> test/jdk/sun/security/ssl/CipherSuite/DisabledCipherSuitesNotNegotiated.java
> line 75:
>
>> 73: }
>> 74:
>> 75: try(SSLSocket clientSocket = (SSLSocket)
>> serverSocket.accept()) {
>
> In the stack from the bug I can see that the thread still hangs in the accept
> but the ExecutorService is in its close() call.
> Perhaps you could use a same timeout value for the server socket to avoid
> blocking this thread forever in case of a timeout. Something like :
> serverSocket.setSoTimeout(WAIT_FOR_SERVER_SECS * 3);
>
> And it would be great if the WAIT_FOR_SERVER_SECS could be multiplied by the
> timeout factor of jtreg to allow for higher timeouts on crowded test machines.
I'm not a fan of adding in another timeout value because it may be tricky to
get it high enough to deal with crowded machines but low enough to not dawdle.
Instead, I updated the test so that the server accept has a short timeout (set
with setSoTimeout()) and every time it times-out, checks for the presence of a
file which will be created if the client cannot connect to the server. I also
reworked the code so the client and server invocations are in their own threads
and use `ExecutorService.invokeAny()` so if there is an error in one thread,
the test does not block in the other.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30680#discussion_r3111990253
