RFR: 8301214: Adjust handshakeTimeout value in test HandshakeTimeout.java after 8189338

[Mark Sheppard]

On Mon, 30 Jan 2023 11:06:05 GMT, Daniel Jeliński <djelinski at openjdk.org> wrote:

> Please review this patch that reduces the socket timeout used in HandshakeTimeout test to its minimum value of 1 millisecond.
> 
> This change makes the test complete 10 seconds faster; before this change it took 5 seconds for the handshake to timeout, and the test attempts 2 handshakes.
> 
> The change also makes the test more likely to pass when it has to compete with other tests for CPU time.

What is the motivation for reducing the timeout for the handshake? 

I think the failure in the bug hints at a few potential issues that may be worth a deeper look.

There are two runs of this test ... plain socket and ssl socket. The failures is on the second ssl scenario. 

This is unexpected and question arises why did it happen. Is it an obscure issue in the RMI layer, or in the SSL layer, or perhaps in the native code associated with "select" for the timeout on the read/write ? 

Reducing the handshake timeout for the first scenario seems ok. But reducing the handshake to 1 millisecond for the ssl scenario maybe masking an issue with the SSL timers or within the RMI layer -- the failure could be suggesting some deeper issues. 

What the failure suggestion is that additional diagnostics would be helpful for determining how the main thread has reached the no timeout condition: 
         if (connector.exception == null) { 
                throw new RuntimeException( 
                    "TEST FAILED: remote call did not time out"); 
            } else { 

Did the Connector thread actually run? Is it in the RTR state waiting to be scheduled when the test completed? is it still alive? should additional state be added to indicate that the Connector thread has started? Should the Connector thread and the main thread synchronise on a countDownLatch before the thread join ? 

Thus, the failure suggests that a bit of restructuring would be useful, to add a bit of Connect run state, or check the state of the Connector thread prior to join, and some synchronization between the Connector thread and the main thread before the join to ensure that the Connector thread has started. The main thread waits for the Connector thread to actually start.

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

PR: https://git.openjdk.org/jdk/pull/12292