hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Leigh <james-nos...@leighnet.ca>
Subject Re: HttpEntity#consumeContent deprecated; was Re: HttpEntity#writeTo and #consumeContent
Date Sat, 10 Apr 2010 15:12:20 GMT
On Fri, 2010-04-09 at 21:12 +0200, Oleg Kalnichevski wrote:
> ...
> 
> > > 
> > > > I still don't understand what should be done if an IOException occurs
> > > > (or RuntimeException) while in the read() method. Must consumeContent
be
> > > > called then? Or, in an exception enough to consider the stream released?
> > > > 
> > > 
> > > When reading from an input stream, #close method should be called from a
> > > finally clause to ensure proper resource release. 
> > > 
> > 
> > Sounds like you think/agree that writeTo implementations should close
> > the inputstream in a finally block (since they read from it). I'll file
> > a bug report and include a patch next week.
> > 
> > James
> > 
> 
> James et al
> 
> I deprecated HttpEntity#consumeContent in favor of a more standard
> InputStream#close contract. Javadocs / tutorial have been updated to
> describe the recommended way to ensure resource deallocation: 
> 
> http://svn.apache.org/viewvc?rev=932551&view=rev
> 
> Please review / comment / critique
> 
> Oleg
> 

Thanks for doing this Oleg. However, it is not clear from the revised
javadocs if getContent().close() must be called if the content is not
read. There needs to be a clear way to free the resources of the
HttpMessage even if the caller does not care to process the HTTP message
body.

I also want to point out another use-case that is relevant here. Often
the HttpResponse is dependent on external resources, such as a database
connections or a read locks, and these need to be closed when the
response message body is consumed. By using InputStream#close() as the
signal to free up resources the implementers are required to wrap the
underlying InputSteam to intercept this call and release locks and/or
free db connections. This prevents some read optimizations to occur.

In the case of a FileInputStream, for example, the OS can bypass
in-memory buffers using FileChannel#transferTo, but a FileInputStream
wound not be detectable if the InputStream was wrapped. However, by
using the ProducingNHttpEntity interface the finish() method allows
implementers to override the clean-up method without interfering with
read optimizations, such as with NFileEntity.

While getContent().close() works there are now many ways to clean-up the
same resources and the javadocs need to be very clear. Perhaps more
information in needed in HttpMessage and its sub-interfaces?

James






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


Mime
View raw message