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-1281) GzipDecompressingEntity does not release InputStream when an IOException occurs while reading the Gzip header
Date Wed, 19 Dec 2012 15:23:12 GMT

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

Oleg Kalnichevski commented on HTTPCLIENT-1281:

> Just for my understanding, are we supposed to be able to call getContent() several times
on a HttpEntity that is not repeatable ?

Yes, we are. The entity would always return the same InputStream instance, though. 

> as far as I have seen, method isStreaming() is used only in org.apache.http.util.EntityUtils.consume(HttpEntity)

Essentially this is the only place where this distinction matters.

> Wouldn't it be better to add a release() method directly to HttpEntity class ? 

You see, this would create certain ambiguity as whether one must call #close on input stream
returned by the #getCcontent method, #release method or both. Besides, not all entities need
to be released. For instance, non-blocking entities are usually just placeholders for content
details such as length, type, encoding and so on. 

With the 4.3 APIs I hope the rules of resource management should become significantly simpler:
(1) always close response regardless of its status code (2) always close input stream obtained
from HttpEntity#getContent. That is it.

More importantly, though, we cannot change HttpEntity interface as long as we do not want
to start the 5.x development cycle and start breaking API compatibility.

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

View raw message