Is there a pattern, like an architecture or platform or specific test case?
This failure was on Ubuntu+JDK11, right? 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.
On Fri, Aug 29, 2025 at 5:35 AM Oleg Kalnichevski <[email protected]> wrote:
> Hi Ryan
>
> There is a trouble with a TLS timeout test case
>
>
> https://ci-builds.apache.org/job/HttpComponents/job/HttpComponents%20Client%205.6.x/95/org.apache.httpcomponents.client5$httpclient5-testing/
>
> Is there anything that could be done to make the test case more stable?
>
> Oleg
>
> -------- Forwarded Message --------
> From: Apache Jenkins Server <[email protected]>
> Reply-To: HttpComponents Project <[email protected]>
> To: [email protected]
> Subject: Jenkins build became unstable: HttpComponents »
> HttpComponents Client 5.6.x #95
> Date: 29.08.2025 02:12:41
>
> See
> <
> https://ci-builds.apache.org/job/HttpComponents/job/HttpComponents%20Client%205.6.x/95/display/redirect?page=changes
> >
>
>
>
