[
https://issues.apache.org/jira/browse/HTTPCLIENT-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17532911#comment-17532911
]
Paul Bakker commented on HTTPCLIENT-2213:
-----------------------------------------
> HttpClient triggers the connection release the same very moment it has
> received the entire response body
That is not what I'm seeing: I'm seeing that releaseConnection is called when
I'm calling `EntityUtils.consume(res.getEntity())`. But before I call
`EntityUtils.consume(res.getEntity())` if I inspect the SessionInputBufferImpl
inside res.getEntity() > content > in, I see the that the entire 'response'
including the body has already been received, as the body content is inside the
buffer. What hasn't happened yet though is that the entire buffer has been
read: in my example the bufferlen = 441, while the bufferPos = 439 (and my
response body is a simple 'OK' string)
So that suggests to me that (at least in my current testcase right now), the
server has send the entire response, that response has been received on the
(http) clientside, but the connection is only released when the clientCode has
read all the content from the buffer.
Maybe I'm just looking at a very narrow usecase of the plethora of usecases
that HTTPCLient supports or maybe my insight into everything going on is
missing a lot of important parts, but I would think that the best time to
calculate the expiry timestamp would be the moment when all response data has
been received from the server, meaning when all the data is available
clientside in the buffer
> 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]
