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

AsynchronousValidationRequest and a connection pool leak

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 4.3.1, 4.3.2
    • 4.3.2
    • HttpCache
    • 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

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

            Dates

              Created:
              Updated:
              Resolved: