[
https://issues.apache.org/jira/browse/HTTPCLIENT-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533206#comment-17533206
]
Oleg Kalnichevski commented on HTTPCLIENT-2213:
-----------------------------------------------
> That is not what I'm seeing: I'm seeing that releaseConnection is called when
> I'm calling `EntityUtils.consume(res.getEntity())`.
[~Paul Bakker] There might be entire the entire message body stuck in the
session buffer, but the message body is considered fully received only after th
receipt of the end of stream (-1). This is exactly what `EntityUtils#consume`.
it just reads the content until the end of stream. You need to improve your
application code to continue reading from the content stream until the end of
stream.
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]
