hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois-Xavier Bonnet (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 11:25:13 GMT

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

Francois-Xavier Bonnet commented on HTTPCLIENT-1281:

It looks fine now. Many thanks for the fix.

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

Other question: as far as I have seen, method isStreaming() is used only in org.apache.http.util.EntityUtils.consume(HttpEntity).
Wouldn't it be better to add a release() method directly to HttpEntity class ? This way we
will better hide the implementation details of HttpEntity to the code that use them and enable
more varied implementations of HttpEntity with maybe something else to release than an InputStream.
Then the rules would be more simple: whenever you get a response with an HttpEntity, you have
to call release() method at the end.
> 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