On Wed, 20 Nov 2024 15:01:16 GMT, Artur Barashev <abaras...@openjdk.org> wrote:
>> SAP complains about SSLSocketNoServerHelloClientShutdown timing out in their
>> test environment (concurrent test execution with high CPU load). This change
>> addresses this issue in 2 ways:
>> - Increase default timeout value
>> - Allow adjustment of timeout value by setting "test.timeout.factor" system
>> property
>
> Artur Barashev has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Print stack trace
test/jdk/sun/security/ssl/SSLCipher/SSLSocketNoServerHelloClientShutdown.java
line 69:
> 67: public SSLSocketNoServerHelloClientShutdown() throws Exception {
> 68: super();
> 69: float timeoutFactor = Float.parseFloat(
Essentially we're is increasing the timeout to 5s from 2s, and that seems to
address the reporter's problem. But using timeouts does add fragility.
A cleaner way might be to use signaling synchronization between client/server
(like the `CountdownLatch` used in the templates), or even just volatiles when
the data is ready for read by the `ServerSocket`/`Socket`. The advantage is
that you have complete control when the app's threads run, with a fallback of
some max time in case of something else goes wrong.
Or alternatively, you could simply have a 5s timeout constant which also seems
to address the problem.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22263#discussion_r1852932609
