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]
