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

Oleg Kalnichevski commented on HTTPCLIENT-1281:
-----------------------------------------------

> I think the confusion is already here. 

InputStream#close() is the _only_ thing which is truly required. 
EntityUtils#consume is merely a convenience method intended for those cases 
when one does not want to read and process the response content.   

> You mean EntityUtils.consume(HttpEntity) or something else ?

CloseableHttpResponse#close()

So, basically the exception handling code should look like that

---
CloseableHttpResponse response = httpclient.execute(httpget);
try {
    HttpEntity entity = response.getEntity();
    if (entity != null) {
        InputStream instream = entity.getContent();
        try {
            instream.read();
        } finally {
            // Closing the input stream will trigger connection release
            instream.close();
        }
    }
} finally {
    response.close();
}
---

Oleg
                
> GzipDecompressingEntity does not release InputStream when an IOException 
> occurs while reading the Gzip header
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1281
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1281
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.2.2, 4.2.3, Snapshot
>            Reporter: Francois-Xavier Bonnet
>            Priority: Blocker
>             Fix For: 4.2.3
>
>         Attachments: DecompressingEntity_patch.txt
>
>
> When calling method 
> org.apache.http.client.entity.DecompressingEntity.getContent() for a 
> GzipDecompressingEntity, the method tries to build a GZIPInputStream, then 
> the GzipInputStream tries to read the Gzip header and fails throwing an 
> IOException.
> At the end you get an Exception but the backend InputStream is never closed 
> resulting in a connection leak.
> Here is a test to reproduce:
>       @Test
>       public void 
> testGzipDecompressingEntityDoesNotCrashInConstructorAndLeaveInputStreamOpen()
>                       throws Exception {
>               final AtomicBoolean inputStreamIsClosed = new 
> AtomicBoolean(false);
>               HttpEntity in = new InputStreamEntity(new InputStream() {
>                       @Override
>                       public int read() throws IOException {
>                               throw new IOException("An exception occurred");
>                       }
>                       @Override
>                       public void close() throws IOException {
>                               inputStreamIsClosed.set(true);
>                       }
>               }, 123);
>               GzipDecompressingEntity gunzipe = new 
> GzipDecompressingEntity(in);
>               try {
>                       InputStream is = gunzipe.getContent();
>               } catch (IOException e) {
>                       // As I cannot get the content, GzipDecompressingEntity 
> is supposed
>                       // to have released everything
>                       Assert.assertTrue(inputStreamIsClosed.get());
>               }
>       }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to