Done. On Mon, Sep 1, 2025 at 9:26 AM Oleg Kalnichevski <[email protected]> wrote:
> On Sat, 2025-08-30 at 21:12 -0700, Ryan Schmitt wrote: > > Is there a pattern, like an architecture or platform or specific test > > case? > > This failure was on Ubuntu+JDK11, right? > > It is JDK11 latest and some sort of Unix. I do presume it is of Debian > / Ubuntu variety. > > > > The synchronous version of this > > test already refuses to run on Java 11: > > > > // There is a bug in Java 11: after the handshake times out, > > the > > SSLSocket implementation performs a blocking > > // read on the socket to wait for close_notify or alert. This > > operation blocks until the read times out, > > // which means that TLS handshakes take twice as long to time > > out > > on Java 11. Without a workaround, the only > > // option is to skip the timeout duration assertions on Java > > 11. > > assumeFalse(determineJRELevel() == 11, "TLS handshake > > timeouts are > > buggy on Java 11"); > > > > The linked assertion failure is for a 2,000ms timeout (500ms > > expected), > > which is well beyond what I'd expect for ordinary test flakiness, > > noisy > > neighbor issues, GC pauses, etc. I'm inclined to just disable the > > test on > > Java 11 if this isn't an isolated incident. > > > > Please do. It is not going to help if this test ends up failing during > a release vote. > > Cheers > > Oleg > >
