On Tue, 2025-07-01 at 11:26 -0700, Ryan Schmitt wrote:
> What is the intended behavior of `setValidateAfterInactivity` on the
> async client with HTTP/1.1 connections? The current implementation
> is:
>
> if (poolEntry.hasConnection()) {
> final ManagedAsyncClientConnection connection =
> poolEntry.getConnection();
> final TimeValue timeValue =
> connectionConfig.getValidateAfterInactivity();
> if (connection.isOpen() && TimeValue.isNonNegative(timeValue)) {
> if (timeValue.getDuration() == 0
> || Deadline.calculate(poolEntry.getUpdated(),
> timeValue).isExpired()) {
> final ProtocolVersion protocolVersion =
> connection.getProtocolVersion();
> if (protocolVersion != null &&
> protocolVersion.greaterEquals(HttpVersion.HTTP_2_0)) {
> connection.submitCommand(new PingCommand(/* ... */,
> Command.Priority.IMMEDIATE);
> return;
> }
> if (LOG.isDebugEnabled()) {
> LOG.debug("{} connection {} is closed", id,
> ConnPoolSupport.getId(connection));
> }
> poolEntry.discardConnection(CloseMode.IMMEDIATE);
> }
> }
> }
>
> In other words, the current implementation is actually just a
> connection TTL. I got a report from someone who was seeing zero
> connection reuse with their client after upgrading to 5.4, and it
> turns out that it's because they were calling
> `setValidateAfterInactivity(0)`. The intention was to _always_ check
> for a stale connection before reuse, but it actually resulted in all
> pooled connections being immediately closed, since 5.4 fixes the
> handling of validateAfterInactivity/connectionTimeToLive being set to
> `0`. This seems like a bug, but does Java provide us any way to fix
> it?
I do not think so. I do not know of a way to reliably perform a
validity check on non-blocking connections other than sending a ping
message. This obviously can only work with HTTP/2 only, so probably
`validateAfterInactivity` should not apply to HTTP/1.1 connections at
all. Generally non-blocking connections should never get stale like
their blocking counterparts.
Oleg
> I thought the usual trick was to perform a blocking read with a
> 1ms timeout, which will surface the fact that the remote peer has
> closed the connection.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
