Uploaded image for project: 'HttpComponents HttpClient'
  1. HttpComponents HttpClient
  2. HTTPCLIENT-1441

AsynchronousValidationRequest and a connection pool leak



    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 4.3.1, 4.3.2
    • Fix Version/s: 4.3.2
    • Component/s: HttpCache
    • Labels:
    • Environment:
      Mac, Centos 6.4


      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:

      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:

      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.

      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?



        1. patchfile.patch
          12 kB
          Dominic Tootell
        2. patchfile.patch
          15 kB
          Dominic Tootell



            • Assignee:
              tootedom Dominic Tootell
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: