There's something weird going on that's only affecting (macos-latest, 11). I can't reproduce it locally, even using the same JRE (Temurin 11.0.27+6) and architecture, although the environment macOS is an older version (14.7.6). The fact that the timeout is taking twice as long as it ought to on JDK11 is reminiscent of the bug I documented here:
https://github.com/apache/httpcomponents-client/blob/fd2870edec85c0a37429fb357f13f844ff755c0c/httpclient5-testing/src/test/java/org/apache/hc/client5/testing/sync/TestTlsHandshakeTimeout.java#L105 However, I've seen both Http and Https tests fail, and the behavior is totally inconsistent. I'm going to relax the assertion, so that the tests pass more reliably. We really just want to verify that the socket timeout during the TLS handshake is indeed the TLS handshake timeout, not the usual socket timeout or connection timeout. On Wed, Jun 18, 2025 at 7:01 AM Oleg Kalnichevski <ol...@apache.org> wrote: > > Hi Ryan > > One of the socket timeout tests failed in one of the environments. > Could you please take a look? > > > ``` > org.apache.hc.client5.testing.sync.TestSocketTimeout$Https.testReadTime > outs(String)[6] > ``` > > https://github.com/apache/httpcomponents-client/actions/runs/15734544257/job/44343633924 > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
