Oleg Kalnichevski updated HTTPASYNC-116:
         Assignee: Oleg Kalnichevski
    Fix Version/s: 4.1.2

> Cancelling the Future returned by CloseableHttpAsyncClient should release all 
> resources allocated to the request that created it.
> ---------------------------------------------------------------------------------------------------------------------------------
>                 Key: HTTPASYNC-116
>                 URL: https://issues.apache.org/jira/browse/HTTPASYNC-116
>             Project: HttpComponents HttpAsyncClient
>          Issue Type: Improvement
>    Affects Versions: 4.1.1
>            Reporter: Rob Griffin
>            Assignee: Oleg Kalnichevski
>             Fix For: 4.1.2
> We call CloseableHttpAsyncClient.execute() to execute HTTP PUTs at the rate 
> of several hundred per minute. Sometimes our web site slows down and does not 
> respond quickly enough and when this occurs the requests back up. We have 
> code that detects this and cancels the Future returned from the execute 
> method when the request has waited too long. If this happens too often the 
> application crashes with an out of memory error. 
> Analysis of a dump showed that there were more 108,000 instances of 
> org.apache.http.nio.pool.LeaseRequest along with a similar number of 
> instances of other HTTP Client classes. Inspecting one of these objects 
> showed that its future variable is not cancelled but that by tracing though 
> the callback variables there is a cancelled Future further up the chain. That 
> cancelled Future object is one returned by execute because its callback is 
> one of our classes. So it appears that the library is unaware that cancel has 
> been called on the Future returned by execute() and keeps a reference to all 
> resources allocated to the request.
> Instead cancelling the Future should release any resources allocated to the 
> request and should also cancel execution if it has started.
> We regard this as a very urgent issue because it causes our application to 
> crash. We realise that improving the responsiveness of our web site will 
> alleviate the problem somewhat but the library shouldn't leak memory. 

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Reply via email to