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:
-----------------------------------------------

Dominic

(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. 
{code}
HttpResponse = null;
try {
  httpResponse = cachingExec.revalidateCacheEntry(...
...
} finally {
    if (httpResponse != null) {
        EntityUtils.consumeQuietly(httpResponse.getEntity());
    }
}
{code}

The code below is perfectly sufficient.

{code}
HttpResponse httpResponse = cachingExec.revalidateCacheEntry(...
try {
...
} finally {
    EntityUtils.consumeQuietly(httpResponse.getEntity());
}
{code}

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

Oleg


> 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