You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2025/08/29 12:35:11 UTC
Trouble with the TLS timeout test case
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 <je...@builds.apache.org>
Reply-To: HttpComponents Project <de...@hc.apache.org>
To: commits@hc.apache.org
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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Trouble with the TLS timeout test case
Posted by Ryan Schmitt <rs...@apache.org>.
Done.
On Mon, Sep 1, 2025 at 9:26 AM Oleg Kalnichevski <ol...@apache.org> 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
>
>
Re: Trouble with the TLS timeout test case
Posted by Oleg Kalnichevski <ol...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Trouble with the TLS timeout test case
Posted by Ryan Schmitt <rs...@apache.org>.
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 <ol...@apache.org> 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 <je...@builds.apache.org>
> Reply-To: HttpComponents Project <de...@hc.apache.org>
> To: commits@hc.apache.org
> 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
> >
>
>
>