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

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
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.

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

Commit messages:
 - update log message
 - add catch clause
 - Merge remote-tracking branch 'upstream/master' into 8241372
 - bind to loopback address instead of wildcard

Changes: https://git.openjdk.java.net/jdk/pull/2405/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241372
  Stats: 29 lines in 4 files changed: 19 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2405.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset

Fernando Guallini-2
On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini <[hidden email]> 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.

@dfuch a similar fix was applied here: https://bugs.openjdk.java.net/browse/JDK-8230858

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

Re: RFR: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset

Daniel Fuchs-2
In reply to this post by Fernando Guallini-2
On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini <[hidden email]> 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.

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

> 27: /*
> 28:  * @test
> 29:  * @bug 4416068 4478803 4479736 8241372

Here and in the other tests:
If a fix is a test bug and only contains test changes, we usually don't add the bug id to the modified tests. Instead we add the label `noreg-self` to the JBS issue. The bug ids in the tests files are supposed to identify *source changes* that can be verified by running the test.

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

> 143:             // The server side may have closed the socket.
> 144:             System.out.println("Client SSLException:");
> 145:             ssle.printStackTrace(System.out);

If security / TLS experts agree that this is OK, then it is OK for me. Not being an expert, I'd be concerned that catching plain SSLException might be too wide and that this might hide errors. In that case, and if the error is intermittent, one possibility could be to respin the test in case of SSLException (do client side and server side again) and fail if the second attempts fails too.

test/jdk/sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java line 90:

> 88:             (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
> 89:         InetSocketAddress socketAddress =
> 90:                 new InetSocketAddress(InetAddress.getLoopbackAddress(), serverPort);

The client is using 127.0.0.1. InetAddress.getLoopbackAddress() might return ::1 (IPv6 loopback) on certain configurations.
Two possibility:
  1. run this test with -Djava.net.preferIPv4Stack to force usage of IPv4, but trivially pass if IPv4 is not available on the machine (see IPSupport in the test library)
  2. use InetAddress.getLoopbackAddress().getHostAddress() on the client side instead of "127.0.0.1"

If you choose 2. you may want to add an additional @run the test with -Djava.net.preferIPv6Address to verify that it works with IPv6 - as there are several ways to represent the IPv6 loopback as a string

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Fernando Guallini-2
> 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 two additional commits since the last revision:

 - Merge branch '8241372' of github.com:fguallini/jdk into 8241372
 - remove not needed bug id from tests, run with preferIPv4Stack

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2405/files
  - new: https://git.openjdk.java.net/jdk/pull/2405/files/2a20a45d..779c3fbf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=00-01

  Stats: 9 lines in 4 files changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2405.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Daniel Fuchs-2
On Thu, 4 Feb 2021 14:50:24 GMT, Daniel Fuchs <[hidden email]> wrote:

>> Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision:
>>
>>  - Merge branch '8241372' of github.com:fguallini/jdk into 8241372
>>  - remove not needed bug id from tests, run with preferIPv4Stack
>
> test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 29:
>
>> 27: /*
>> 28:  * @test
>> 29:  * @bug 4416068 4478803 4479736 8241372
>
> Here and in the other tests:
> If a fix is a test bug and only contains test changes, we usually don't add the bug id to the modified tests. Instead we add the label `noreg-self` to the JBS issue. The bug ids in the tests files are supposed to identify *source changes* that can be verified by running the test.

Done

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Daniel Fuchs-2
On Thu, 4 Feb 2021 15:11:39 GMT, Daniel Fuchs <[hidden email]> wrote:

>> Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision:
>>
>>  - Merge branch '8241372' of github.com:fguallini/jdk into 8241372
>>  - remove not needed bug id from tests, run with preferIPv4Stack
>
> test/jdk/sun/security/ssl/SSLSocketImpl/ReverseNameLookup.java line 90:
>
>> 88:             (SSLServerSocketFactory) SSLServerSocketFactory.getDefault();
>> 89:         InetSocketAddress socketAddress =
>> 90:                 new InetSocketAddress(InetAddress.getLoopbackAddress(), serverPort);
>
> The client is using 127.0.0.1. InetAddress.getLoopbackAddress() might return ::1 (IPv6 loopback) on certain configurations.
> Two possibility:
>   1. run this test with -Djava.net.preferIPv4Stack to force usage of IPv4, but trivially pass if IPv4 is not available on the machine (see IPSupport in the test library)
>   2. use InetAddress.getLoopbackAddress().getHostAddress() on the client side instead of "127.0.0.1"
>
> If you choose 2. you may want to add an additional @run the test with -Djava.net.preferIPv6Address to verify that it works with IPv6 - as there are several ways to represent the IPv6 loopback as a string

Applied the first suggestion since, it is using 127.0.0.1 for verification later in the test. Thanks

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Daniel Fuchs-2
In reply to this post by Fernando Guallini-2
On Fri, 5 Feb 2021 10:48:00 GMT, Fernando Guallini <[hidden email]> 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 two additional commits since the last revision:
>
>  - Merge branch '8241372' of github.com:fguallini/jdk into 8241372
>  - remove not needed bug id from tests, run with preferIPv4Stack

The new changes look goo to me. Please wait to get approval from someone from security-dev before pushing.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Rajan Halade-2
In reply to this post by Daniel Fuchs-2
On Thu, 4 Feb 2021 14:55:39 GMT, Daniel Fuchs <[hidden email]> wrote:

>> Fernando Guallini has updated the pull request incrementally with two additional commits since the last revision:
>>
>>  - Merge branch '8241372' of github.com:fguallini/jdk into 8241372
>>  - remove not needed bug id from tests, run with preferIPv4Stack
>
> test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 145:
>
>> 143:             // The server side may have closed the socket.
>> 144:             System.out.println("Client SSLException:");
>> 145:             ssle.printStackTrace(System.out);
>
> If security / TLS experts agree that this is OK, then it is OK for me. Not being an expert, I'd be concerned that catching plain SSLException might be too wide and that this might hide errors. In that case, and if the error is intermittent, one possibility could be to respin the test in case of SSLException (do client side and server side again) and fail if the second attempts fails too.

You can use getCause() to examine reason for SSLException.

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Fernando Guallini-2
> 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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2405/files
  - new: https://git.openjdk.java.net/jdk/pull/2405/files/779c3fbf..382a389a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=01-02

  Stats: 23 lines in 1 file changed: 12 ins; 7 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2405.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Rajan Halade-2
On Fri, 5 Feb 2021 17:45:45 GMT, Rajan Halade <[hidden email]> wrote:

>> test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 145:
>>
>>> 143:             // The server side may have closed the socket.
>>> 144:             System.out.println("Client SSLException:");
>>> 145:             ssle.printStackTrace(System.out);
>>
>> If security / TLS experts agree that this is OK, then it is OK for me. Not being an expert, I'd be concerned that catching plain SSLException might be too wide and that this might hide errors. In that case, and if the error is intermittent, one possibility could be to respin the test in case of SSLException (do client side and server side again) and fail if the second attempts fails too.
>
> You can use getCause() to examine reason for SSLException.

Sure. Narrowed down SSLException handling by using getCause() in last commit.

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Daniel Fuchs-2
In reply to this post by Fernando Guallini-2
On Fri, 5 Feb 2021 20:48:56 GMT, Fernando Guallini <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Fernando Guallini-2
> 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:

  check exception type

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2405/files
  - new: https://git.openjdk.java.net/jdk/pull/2405/files/382a389a..8acf751a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=02-03

  Stats: 16 lines in 1 file changed: 12 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2405.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Daniel Fuchs-2
On Wed, 10 Feb 2021 12:24:15 GMT, Daniel Fuchs <[hidden email]> wrote:

>> 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 where 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.

Yes, added the verification to check if it is instanceof SocketException

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Daniel Fuchs-2
In reply to this post by Fernando Guallini-2
On Thu, 11 Feb 2021 12:08:54 GMT, Fernando Guallini <[hidden email]> 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:
>
>   check exception type

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

> 153:                 && "Connection reset".equals(cause.getMessage())) {
> 154:             System.out.println("Client SSLException:");
> 155:             ssle.printStackTrace(System.out);

Sorry for nit picking - but I would keep that tracing in the catch clause above.

        } catch (SSLException ssle) {
            if (isConnectionReset(ssle)) {
                System.out.println("Client SSLException:");
                ssle.printStackTrace(System.out);
            } else {
                 failTest(ssle, "Client got UNEXPECTED SSLException:");
            }
        }
 ```

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Fernando Guallini-2
> 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:

  refactor isConnectionReset method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2405/files
  - new: https://git.openjdk.java.net/jdk/pull/2405/files/8acf751a..aa0e1468

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2405&range=03-04

  Stats: 11 lines in 1 file changed: 3 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2405.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2405/head:pull/2405

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Fernando Guallini-2
In reply to this post by Daniel Fuchs-2
On Thu, 11 Feb 2021 12:17:41 GMT, Daniel Fuchs <[hidden email]> wrote:

>> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
>>
>>   check exception type
>
> test/jdk/javax/net/ssl/SSLSession/TestEnabledProtocols.java line 155:
>
>> 153:                 && "Connection reset".equals(cause.getMessage())) {
>> 154:             System.out.println("Client SSLException:");
>> 155:             ssle.printStackTrace(System.out);
>
> Sorry for nit picking - but I would keep that tracing in the catch clause above.
>
>         } catch (SSLException ssle) {
>             if (isConnectionReset(ssle)) {
>                 System.out.println("Client SSLException:");
>                 ssle.printStackTrace(System.out);
>             } else {
>                  failTest(ssle, "Client got UNEXPECTED SSLException:");
>             }
>         }
>  ```

That is perfectly fine. It does make it a bit more legible.

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Daniel Fuchs-2
In reply to this post by Fernando Guallini-2
On Thu, 11 Feb 2021 12:39:54 GMT, Fernando Guallini <[hidden email]> 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:
>
>   refactor isConnectionReset method

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

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

Rajan Halade-2
In reply to this post by Fernando Guallini-2
On Thu, 11 Feb 2021 12:39:54 GMT, Fernando Guallini <[hidden email]> 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:
>
>   refactor isConnectionReset method

Marked as reviewed by rhalade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2405
Reply | Threaded
Open this post in threaded view
|

Integrated: 8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset

Fernando Guallini-2
In reply to this post by Fernando Guallini-2
On Thu, 4 Feb 2021 13:00:47 GMT, Fernando Guallini <[hidden email]> 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.

This pull request has now been integrated.

Changeset: 0a50688d
Author:    Fernando Guallini <[hidden email]>
Committer: Rajan Halade <[hidden email]>
URL:       https://git.openjdk.java.net/jdk/commit/0a50688d
Stats:     58 lines in 4 files changed: 42 ins; 7 del; 9 mod

8241372: Several test failures due to javax.net.ssl.SSLException: Connection reset

Reviewed-by: dfuchs, rhalade

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

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