You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Paul Bakker (Jira)" <ji...@apache.org> on 2022/05/05 08:20:00 UTC

[jira] [Created] (HTTPCLIENT-2213) Mechanism to not use pooled connections beyond the keep-alive period is flawed

Paul Bakker created HTTPCLIENT-2213:
---------------------------------------

             Summary: Mechanism to not use pooled connections beyond the keep-alive period is flawed
                 Key: HTTPCLIENT-2213
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2213
             Project: HttpComponents HttpClient
          Issue Type: Bug
          Components: HttpClient (async), HttpClient (classic)
    Affects Versions: 4.5.13, 5.1.4
            Reporter: Paul Bakker


When making a request using the HTTPClient to an endpoint that returns a Keep-Alive header in the response with a timeout value of say 5 seconds, then in org.apache.http.impl.execchain.MainClientExec.execute, directly after the request was made the timeout value (5 seconds) from the response is stored on the ConnectionHolder by making a call to ConnectionHolder.setValidFor(...).

This value stored on the ConnectionHolder is used once the connection is released back to the connection pool, in PoolingHttpClientConnectionManager.releaseConnection(...), by making a call to PoolEntry.updateExpiry(...).

The .updateExpiry() method then updates its 'expiry' field with the timestamp when the connection is to be considered not valid anymore (which gets checked when leasing a connection from the pool).

However, the logic in .updateExpiry(..) to calculate the new `expiry` timestamp basically does `System.currentTimeMillis() + duration` (with duration being 5 seconds in this example). This is problematic, because the 5 seconds Keep-Alive interval is relative to the moment to receiving the response in the aforementioned .execute(...) method. The calculation in .updateExpiry(...) however calculates it reletive to the moment that .updateExpiry(...) is called, which, depending on the implementation, could be quite some time later, which could result inPoolingHttpClientConnectionManager. leaseConnection(...) returning a connection from the pool, which isn't alive anymore.

  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org