Correction: the issue is in TestSocketTimeout, and we want to ensure that all three ways of setting the socket timeout take effect. The test expects a `SocketTimeoutException`, so we'll know if it stops working.
On Thu, Jun 19, 2025 at 8:16 AM Ryan Schmitt <rschm...@apache.org> wrote: > > 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
