On Fri, 5 Feb 2021 20:48:56 GMT, Fernando Guallini <[email protected]>
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
