Hi Oleg, Thanks for taking the time to answer. I totally understand that you guys can't please everyone, my only ask would be a non hackish way to override this behavior, I've logged my ideas in https://issues.apache.org/jira/browse/HTTPCLIENT-2434.
As for the 10 seconds being agressive, you're right and I've raised this to 20 seconds internally. Just as a point of reference though, the default idle timeout of Jetty is 30 seconds so putting something higher than that could cause some weird exceptions where the client use a connection that is currently being terminated by Jetty but still considered alive by httpclient. Thanks again for your answer, much appreciated! Jacques-Etienne On Thu, Sep 17, 2026 at 2:38 PM Oleg Kalnichevski <[email protected]> wrote: > On Thu, 2026-09-17 at 11:27 -0400, [email protected] wrote: > > Hello, > > > > We recently moved from HttpClient 5.5 to 5.6.1 and started seeing > > connection request timeouts on certain bursty traffic patterns. These > > bubble up as RequestFailedException. Our connection pool config was > > left > > unchanged during the migration and has a pretty "standard" setup I'd > > say : > > > > var connectionPool = > > PoolingHttpClientConnectionManagerBuilder.create() > > > > .setMaxConnTotal(200) > > > > .setMaxConnPerRoute(100) > > > > .build(); > > var httpClient = HttpClientBuilder.create() > > > > .setConnectionManager(connectionPool) > > > > .setDefaultRequestConfig(RequestConfig.custom() > > > > .setConnectionRequestTimeout(Timeout.ofSeconds(1)) > > .build()) > > > > .evictIdleConnections(Timeout.ofSeconds(10)) > > .build(); > > > > I traced changes down a bit and I believe the cause is the change > > from > > HTTPCLIENT-2388 / PR #714. In 5.5, HttpClientBuilder passed sleepTime > > = > > maxIdleTime, so the evictor swept every 10 seconds. In 5.6 it passes > > null, > > and calculateSleepTime() returns maxIdleTime/10 with a one second > > floor, so > > it now sweeps every second. That is ten times more often, and there > > is no > > way to set sleepTime through the builder. > > > > The higher frequency causes a contention issue because closing > > idle/expired > > connections is, when using the StrictConnPool, not lock free, and the > > DefaultDisposalCallback > > impose a timeout of 1 second when disposing connections. We believe > > this is > > the cause of the sporadic issues we've been seeing. I've included a > > redacted stack trace at the end of the email > > > > This being said, I understand the nature of the changes and the > > desire to > > close idle connections closer to their desired idle time. Therefore, > > I > > think these 2 options could make sense : > > > > - Allow the easy customization of the sleepTime in HttpClientBuilder > > (and > > its async builder buddy) > > - Reconsider the divisor used to calculate the sleepTime. Using 10 > > might > > make sense for an idle timeout of 100 seconds, but less for an idle > > timeout > > of 10. > > > > I know about the off lock disposal new feature and I'm gonna try it > > in > > order to fix the issue, but I still think it's worthy of checking it > > since > > that off lock disposal is still experimental and disabled by default. > > > > Thanks to all! > > > > Jacques-Etienne > > Hi Jacques-Etienne > > Please note: > > 1. Evicting connections after 10 seconds of inactivity sounds a bit > extreme. I would say anything belong 1 minute is excessive > > 2. There is nothing stopping you starting IdleConnectionEvictor > manually with whatever settings you deem best or even building your > own. > > We cannot please everyone. Those changes have been made per change > request https://issues.apache.org/jira/browse/HTTPCLIENT-2388 as you > have mentioned. > > Please create a JIRA, link it to HTTPCLIENT-2388 and describe what you > would like implemented differently. We will see if your request can be > implemented without reverting HTTPCLIENT-2388. > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
