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

AsynchronousValidationRequest and a connection pool leak

    XMLWordPrintableJSON

    Details

    • 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

      Description

      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?

      thanks
      /dom

        Attachments

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

          Activity

            People

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

              Dates

              • Created:
                Updated:
                Resolved: