Dominic Tootell created HTTPCLIENT-1441:
-------------------------------------------
Summary: 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
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]
