RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset [v3]

[Daniel Fuchs]

On Fri, 5 Feb 2021 20:48:56 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

>> The server side is binding to the wildcard address which has been a source of instability in many networking tests due to javax.net.ssl.SSLException: Connection reset. Changing the following tests to bind to loopback address fixes intermittent failures:
>> sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java
>> javax/net/ssl/TLSCommon/TLSTest.java
>> sun/security/ssl/CipherSuite/SupportedGroups.java
>> 
>> 
>> javax/net/ssl/SSLSession/TestEnabledProtocols.java still throws a connection reset occasionally because the server closes the connection before the client is done during handshake. That race condition cannot be completely removed in this test, thus is now handled and logged.
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   narrow down connection reset handling

test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 142:

> 140:             if ("Connection reset".equals(ssle.getCause().getMessage())) {
> 141:                 System.out.println("Client SSLException:");
> 142:                 ssle.printStackTrace(System.out);

An SSLException doesn't necessarily have a nested `cause` - so you could get a NPE here.
I would suggest moving that code to a `private boolean isConnectionReset(SSLException ssle)` method, and possibly checking the type of the `cause` exception as well. I'm guessing it should be a `SocketException`?
If you check the type then it will also exclude the case were the cause is null and avoid the NPE.
Additional note: as a general rule, relying on exception message is fragile. But since we don't have a specific subtype for "Connection reset" it's probably the best we can do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2405