On Thu, 2026-09-17 at 15:57 -0400, [email protected] wrote:
> 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.
>
Jacques-Etienne
Jetty should be sending `Keep-Alive: 30` header in its response to
inform the client it intends to keep the connection alive for 30
seconds only. If it does not, it is on Jetty.
Still, you are going about the whole thing wrong. Instead of hammering
the pool with calls to evict idle connections every 20 senconds, you
should make idle connections simply expire after 30 seconds of
inactivity and evict expired connections by lazily sweeping the pool
every 3 minutes or so.
```
final CloseableHttpClient httpclient = HttpClients.custom()
.evictExpiredConnections()
.setDefaultRequestConfig(RequestConfig.custom()
.setConnectionKeepAlive(TimeValue.ofSeconds(30))
.build())
.build();
```
Oleg
> 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]
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
