[
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.
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]
