On Thu, 21 Nov 2024 21:30:02 GMT, Bradford Wetmore <wetm...@openjdk.org> wrote:
>> 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.
Thanks for suggestion, Brad. I've added CountDownLatch mechanism, increasing a
fallback scenario timeout value to 30s.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/22263#discussion_r1854328018
