[
https://issues.apache.org/jira/browse/HTTPCLIENT-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532279#comment-17532279
]
Paul Bakker commented on HTTPCLIENT-2213:
-----------------------------------------
[~olegk] I understand that connection expiry timeout isn't excact science, but
I think the current logic is just flawed. Instead of storing the (5 second)
timeout using ConnectionHolder.setValidFor(...), it should instead record the
expiry time, by doing the calculation (System.currentTimeMillis() + duration)
right there, directly after the response was received. And then further down
the line that value just needs to be copied over, all the way to
PoolEntry.updateExpiry(...), so there's no calculation happening anymore inside
the .updateExpiry method.
That way the expiry timestamp is not dependant anymore on the moment the
connection gets released back to the pool
> 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]
