On Fri, 10 Apr 2026 17:11:44 GMT, Matthew Donovan <[email protected]> wrote:
> This timeout may be caused by different code paths used to resolve
> `InetAddress.getLoopbackAddress()` in the server thread and
> `factory.createSocket("localhost",...)` in the client thread. I updated the
> test to use getLoopbackAddress() for both threads.
>
>
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK
> Interim AI Policy](https://openjdk.org/legal/ai).
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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30680#discussion_r3072830962
