Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Date: Wed, 22 Apr 2009 15:29:07 +0200
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
Subject: Re: Weird problems with httpclient 4.0beta2 and httpcore 4.0
Message-ID: <20090422132907.GA30932@ok2cons2.nine.ch>
Mail-Followup-To: HttpClient User Discussion <httpclient-users@hc.apache.org>
References: 
 <8CAF6A21E6DE484DABFBCF990223F650100EC8@ag00-exmbx06.allegisgroup.com>
 <19196d860904211401s5af4b6acu7b6392ecc4ef0def@mail.gmail.com>
 <20090422100151.GB2037@ok2cons2.nine.ch>
 <8CAF6A21E6DE484DABFBCF990223F650100EC9@ag00-exmbx06.allegisgroup.com>
 <8CAF6A21E6DE484DABFBCF990223F650100ECA@ag00-exmbx06.allegisgroup.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <8CAF6A21E6DE484DABFBCF990223F650100ECA@ag00-exmbx06.allegisgroup.com>
User-Agent: Mutt/1.5.18 (2008-05-17)

On Wed, Apr 22, 2009 at 09:15:26AM -0400, Jeudy, Guillaume wrote:
> By reading through DefaultHttpClient & HttpRequestDirector code I see that the BasicHttpEntity is wrapped within a BasicManagedEntity. When BasicManagedEntity.getContent() is called it wraps the InputStream inside a EofSensorInputStream which will properly release the connection when the end of the stream is reached.
>  
> That seems to make sense, the only remaining case is if an exception occurs to ensure release in this case should I call consumeContent() in a finally block?
> 
> HttpResponse httpResponse = null;
> try {
>      httpResponse = httpClient.execute(httpRequest)
> } catch(IOException e) {
>     httpResponse.getEntity().consumeContent();
>     throw e;
> }
> Obviously some null checks and try catch blocks should be added to ensure no additionnal exceptions are thrown from the finally{} block.

EofSensorInputStream will automatically release the connection on any I/O exception. If #consumeContent causes an I/O exception for whatever reason you do not have to worry.

Oleg


> 
> Thanks,
> -Guillaume
> 
> 
> ________________________________
> 
> From: Jeudy, Guillaume [mailto:gjeudy@teksystems.com]
> Sent: Wed 4/22/2009 8:53 AM
> To: HttpClient User Discussion
> Subject: RE: Weird problems with httpclient 4.0beta2 and httpcore 4.0
> 
> 
> 
> 
> 
> ________________________________
> 
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Wed 4/22/2009 6:01 AM
> To: HttpClient User Discussion
> Subject: Re: Weird problems with httpclient 4.0beta2 and httpcore 4.0
> 
> 
> 
> On Tue, Apr 21, 2009 at 05:01:45PM -0400, Sam Berlin wrote:
> > >
> > >
> > > Is using a ResponseHandler the reason why the HttpEntity response is
> > > consumed eagerly in DefaultHttpClient?
> >
> >
> > Yes.  I haven't used ResponseHandler's myself, but what I remember from
> > their introduction is that the concept is that a ResponseHandler takes an
> > HttpResponse and converts it to an Object.   In order to construct the
> > object, it must read the response.  The idea behind ResponseHandler is that
> > it has the "read the response & perform some logic based on it" built in, so
> > that you can reuse the logic easily.  If you have no need to perform any
> > action based on the response, don't supply a ResponseHandler.  If you do
> > have some action that would be performed on a response, it should all be
> > done within the ResponseHandler's handleResponse.
> >
> > I'm not sure I fully understand the stack trace, though -- is that from
> > after execute on HttpClient has returned, or during it?  Is the exception
> > being triggered within a ResponseHandler's handleResponse method?  If so,
> > this may be a different issue.  HttpClient 4 has an "EofSensorInputStream"
> > that will automatically close the stream once you read to the end of the
> > response's content length.  This may be an issue that the Decoder.peek is
> > trying to peek beyond the end of the stream.
> >
> > Sam
> >
> >
> 
> >I think the cause of the problem is that the StAX builder is trying to read
> >from a closed input stream for some reason. I guess HttpClient 3.1 was more
> >lenient about such cases. You should review and possibly revise the test case.
> >
> >Oleg
> 
> Sorry if I wasn't clear, the stacktrace comes after HttpClient execute() call returned and the ResponseHandler was executed. I think the HttpClient 3.1 populates the response in HttpMethodBase and that response is non-repeatable when getResponseAsStream() is called. That is what the axis2 transport was doing. In light of this
> and in order to replicate previous functionality I am forced not to use HttpClient 4.0 ResponseHandler pattern, I will have to
> handle the response separately. The upper layer (OutInAxisOperationClient) expects an InputStream returned from the transport operation so I can't use a ResponseHandler in this case.
> 
> My only concern is how to ensure the underlying connection is released? Is reading through the end of the InputStream enough to release the connection? Or should I absolutely call entity.consumeContent() in order to achieve this ? The upper layer is not aware of HttpEntity object because it is transport protocol agnostic.
> 
> Guillaume
> > >
> > >
> > > See I/O exception i'm currently getting:
> > >
> > > java.io.IOException: Attempted read from closed stream.
> > >  at
> > > org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:145)
> > >  at
> > > org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:175)
> > >  at
> > > org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:178)
> > >  at com.sun.xml.fastinfoset.Decoder.peek(Decoder.java:1817)
> > >  at
> > > com.sun.xml.fastinfoset.Decoder._isFastInfosetDocument(Decoder.java:1869)
> > >  at com.sun.xml.fastinfoset.Decoder.decodeHeader(Decoder.java:1262)
> > >  at
> > > com.sun.xml.fastinfoset.stax.StAXDocumentParser.next(StAXDocumentParser.java:220)
> > >  at
> > > org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:506)
> > >  at
> > > org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:161)
> > >  at
> > > org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.getSOAPEnvelope(StAXSOAPModelBuilder.java:156)
> > >  at
> > > org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.<init>(StAXSOAPModelBuilder.java:105)
> > >  at
> > > org.apache.axis2.fastinfoset.FastInfosetBuilder.processDocument(FastInfosetBuilder.java:57)
> > >  at
> > > org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:164)
> > >  at
> > > org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:112)
> > >  at
> > > org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:88)
> > >  at
> > > org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:353)
> > >  at
> > > org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:416)
> > >  at
> > > org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
> > >  at
> > > org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
> > >  at
> > > org.apache.axis2.fastinfoset.SimpleAddServiceStub.addStrings(SimpleAddServiceStub.java:740)
> > >  at
> > > org.apache.axis2.fastinfoset.SimpleAddServiceClient.addStrings(SimpleAddServiceClient.java:104)
> > >  at
> > > org.apache.axis2.fastinfoset.FastInfosetTest.testAdd(FastInfosetTest.java:49)
> > >  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >  at
> > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> > >  at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> > >  at java.lang.reflect.Method.invoke(Method.java:585)
> > >  at junit.framework.TestCase.runTest(TestCase.java:168)
> > >  at junit.framework.TestCase.runBare(TestCase.java:134)
> > >  at junit.framework.TestResult$1.protect(TestResult.java:110)
> > >  at junit.framework.TestResult.runProtected(TestResult.java:128)
> > >  at junit.framework.TestResult.run(TestResult.java:113)
> > >  at junit.framework.TestCase.run(TestCase.java:124)
> > >  at junit.framework.TestSuite.runTest(TestSuite.java:232)
> > >  at junit.framework.TestSuite.run(TestSuite.java:227)
> > >  at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> > >  at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> > >  at junit.framework.TestResult.runProtected(TestResult.java:128)
> > >  at junit.extensions.TestSetup.run(TestSetup.java:27)
> > >  at
> > > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> > >  at
> > > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
> > >  at
> > > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> > >  at
> > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> > >  at
> > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> > >  at
> > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> > >  at
> > > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> > > Apr 21, 2009 3:43:11 PM org.apache.axis2.deployment.DeploymentEngine
> > > prepareRepository
> > >
> > > Please advise,
> > > Thanks,
> > > -Guillaume
> > >
> > >
> > >
> > > ____________________________________________________________________________________________________
> > > This electronic mail (including any attachments) may contain information
> > > that is privileged, confidential, and/or otherwise protected from disclosure
> > > to anyone other than its intended recipient(s). Any dissemination or use of
> > > this electronic email or its contents (including any attachments) by persons
> > > other than the intended recipient(s) is strictly prohibited. If you have
> > > received this message in error, please notify us immediately by reply email
> > > so that we may correct our internal records. Please then delete the original
> > > message (including any attachments) in its entirety. Thank you.
> > >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 
> 
> 
> 
> 
> 
> ____________________________________________________________________________________________________
> This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.
> 
> 
> 
> 
> ____________________________________________________________________________________________________
> This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you.

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org