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: [email protected] For additional commands, e-mail: [email protected]
