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] [Commented] (HTTPCLIENT-1441) AsynchronousValidationRequest and a connection pool leak
Date Sun, 01 Dec 2013 15:41:36 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836049#comment-13836049
] 

Dominic Tootell commented on HTTPCLIENT-1441:
---------------------------------------------

(1) thanks.  I thought as much.  Is there an example in the current code base you can point
me to so that I can adapt the test case to use the embeedable local test server that HttpClient
has?

(2) The revalidateCacheEntry method throw has checked exceptions throw.  If the call is outside
the try block, then the finally will not be called and you still have the chance that a leak
can occur.

(3) thanks for the clarification.

/dom

> 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
>              Labels: patch
>             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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message