[
https://issues.apache.org/jira/browse/HTTPCLIENT-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836049#comment-13836049
]
Dominic Tootell commented on HTTPCLIENT-1441:
---------------------------------------------
(1) thanks. I thought as much. Is there an example in the current code base
you can point me to so that I can adapt the test case to use the embeedable
local test server that HttpClient has?
(2) The revalidateCacheEntry method throw has checked exceptions throw. If the
call is outside the try block, then the finally will not be called and you
still have the chance that a leak can occur.
(3) thanks for the clarification.
/dom
> 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]
