On Thu, 30 Apr 2026 14:23:12 GMT, Daniel Jeliński <[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 >> >> >> >> --------- >> - [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. Thanks @djelinski for the reviews and suggesttions ------------- PR Comment: https://git.openjdk.org/jdk/pull/30995#issuecomment-4384955962
