hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominic Tootell (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HTTPCLIENT-1441) AsynchronousValidationRequest and a connection pool leak
Date Sun, 01 Dec 2013 14:10:35 GMT
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


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?


This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message