[
https://issues.apache.org/jira/browse/HTTPCLIENT-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532291#comment-17532291
]
Oleg Kalnichevski commented on HTTPCLIENT-2213:
-----------------------------------------------
> it should instead record the expiry time, by doing the calculation
> (System.currentTimeMillis() + duration) right there, directly after the
> response was received
[~Paul Bakker] What makes you think this is the correct / standard behavior?
What makes you think this value defines the period of time starting from the
receipt of the HTTP response _head_ and not the _entire_ HTTP response message?
Oleg
> 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: Improvement
> Components: HttpClient (async), HttpClient (classic)
> Affects Versions: 4.5.13, 5.1.4
> Reporter: Paul Bakker
> Priority: Minor
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
