hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1441) AsynchronousValidationRequest and a connection pool leak
Date Sun, 01 Dec 2013 15:37:36 GMT

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

Oleg Kalnichevski commented on HTTPCLIENT-1441:


(1) I am not convinced we need dependency on another HTTP framework given that HttpClient
has its own embeddable local test server. Would it be a big deal for you to port your test
case to the standard testing framework for the consistency sake?

(2) Minor nitpick. This kind of convoluted exception handling is absolutely unnecessary. 
HttpResponse = null;
try {
  httpResponse = cachingExec.revalidateCacheEntry(...
} finally {
    if (httpResponse != null) {

The code below is perfectly sufficient.

HttpResponse httpResponse = cachingExec.revalidateCacheEntry(...
try {
} finally {

(3) Regarding HTTPCLIENT-1425 not calling super.close() is perfectly OK. Closing the response
is enough.


> 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
> - 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?
> thanks
> /dom

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