On Thu, 30 Apr 2026 02:44:58 GMT, SendaoYan <[email protected]> wrote:
> Hi all, > > ## Problem tobe fixed > > The `empty` ssub-test of javax/net/ssl/ciphersuites/DisabledAlgorithms.java > could hang util the jtreg timeout expires when the TLS handshake stalled > after an error (e.g. server reports "Unsupported or unrecognized SSL message" > while the client blocks in the handshake/read path). The stack trace and the > detial test log shows in the JBS issue. > > In addition, the `default` subtest (failure path) contains a flaky assertion > which required the server to observe an SSL exception. In some runs the > client fails early (as expected) before the server get far enough to throw an > SSL handshake exception, cause intermittent failres like "Expected SSL > exception not thrown on server side". > > ## Fix solution in this PR > > - Make the handshake bounded and deteministic: > - Configure `SOCKET_TIMEOUT` on both client and server SSLSocket instances > - Explicitly call `SSlSocket.startHandShake()` on both sides. > - Avoid cross-connection interference: > - Run each ciper suite against it's own server instance congifured with > that single suite. > - Remove the extra application-data exho exchange, this test only needs the > handshake and negotiated cipher suite. > - Fix the flaky expectations in the failure path: > - Accept the expected handshake failure if it is observed by either the > client or the server. > > ## Additonal testing: > > - [ ] Run the test 10k times on linux-x64 > - [ ] Run the test 10k times on linux-aarch64 > > > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). That's an interesting issue. "Unsupported or unrecognized SSL message" most likely means that an unexpected non-TLS client connected to the test server. It's an SSLException, which is unfortunate because the server stops when it sees one. Does this problem happen frequently? Could you check if the unexpected connection comes from the local machine? You could print `socket.getRemoteSocketAddress()` before starting the handshake. Also, binding to loopback address would filter out connections coming from other machines (use `createServerSocket(0, 0, InetAddress.getLoopbackAddress())`). The problem with server-side exception checking exists only because you're creating a separate server for every client now. Note that the exception thrown on the server side is the same every time, and does not depend on what the client sends - in fact, the server doesn't even try to read from the socket before failing. Before your changes the test only checked that at least one test case caused an error on the server side. I think that was good enough. Could you revert the changes related to creating individual server instances? You removed the `stopped=true` line from the `catch IOException` path, this alone should be sufficient to fix the reported issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30995#issuecomment-4353258661
