[
https://issues.apache.org/jira/browse/HTTPCLIENT-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836048#comment-13836048
]
Oleg Kalnichevski commented on HTTPCLIENT-1441:
-----------------------------------------------
Dominic
(1) I am not convinced we need dependency on another HTTP framework given that
HttpClient has its own embeddable local test server. Would it be a big deal for
you to port your test case to the standard testing framework for the
consistency sake?
(2) Minor nitpick. This kind of convoluted exception handling is absolutely
unnecessary.
{code}
HttpResponse = null;
try {
httpResponse = cachingExec.revalidateCacheEntry(...
...
} finally {
if (httpResponse != null) {
EntityUtils.consumeQuietly(httpResponse.getEntity());
}
}
{code}
The code below is perfectly sufficient.
{code}
HttpResponse httpResponse = cachingExec.revalidateCacheEntry(...
try {
...
} finally {
EntityUtils.consumeQuietly(httpResponse.getEntity());
}
{code}
(3) Regarding HTTPCLIENT-1425 not calling super.close() is perfectly OK.
Closing the response is enough.
Oleg
> AsynchronousValidationRequest and a connection pool leak
> --------------------------------------------------------
>
> Key: HTTPCLIENT-1441
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1441
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpCache
> Affects Versions: 4.3.1, 4.3.2
> Environment: Mac, Centos 6.4
> Reporter: Dominic Tootell
> Labels: patch
> Fix For: 4.3.2
>
> Attachments: patchfile.patch
>
>
> A connection is leaked/not returned to the pool by the
> AynchronousValidationRequest. The reason being that it does not full consume
> the Entity body in all circumstances.
> The scenario is as follows:
> - max-age and stale-while-revalidate is issued by the server
> - When max-age expires, but stale-while-revalidate is still valid a request
> for the cached item is served from cache, but a background revalidation of
> the expired content is executed.
> - When background revalidation of fresh content is fetched from the backend
> (upstream). There is a possibility that this refreshed content is now larger
> than that of the previous entry.
> - When this new refreshed content is greater than the maximum byte size that
> we allow for a single item in the cache. The response's Entity is not
> consumed. As a result the connection in the pool is not closed correctly;
> and a connection from the pool is lost.
> This can be seen in the test case here:
> - https://github.com/tootedom/ConnectionLeakStaleWhileRevalidate
> I have witnessed the exhaustion of the connection pool on a couple of live
> production servers after they had been running for a period of time.
> -----
> I have tested and prepared a potential patch for the issue:
> - https://github.com/apache/httpclient/pull/7
> I will also attach a patch file creating via git, incase it makes it easier
> to read/apply to to svn master. Apologies surrounding the test case, as it
> pulls in an added dependency to set up a mock http server. I couldn't think
> of another way to represent the issue with EasyMock.
> -----
> Just as a side question (I apologies for the side tracking), whilst I was
> investigating this issue I came across the following jira, and I was curious
> about the applied patch.
> - https://issues.apache.org/jira/browse/HTTPCLIENT-1425
> in 1425b patch. The proxyied CloseableHttpResponse in
> SizeLimitedResponseReader includes a super.close(). But the patches applied
> to trunk miss the super.close(). Is the super.close() needed in order to
> ensure the closure of resources?
> thanks
> /dom
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
