On Mon, 2010-04-12 at 09:04 -0400, James Leigh wrote: > On Sat, 2010-04-10 at 17:43 +0200, Oleg Kalnichevski wrote: > > On Sat, 2010-04-10 at 11:12 -0400, James Leigh wrote: > > > > > > 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. > > > > The trouble is this very much depends on the connection management > > logic, which is out of scope for HttpCore. If one does not intent to > > re-use the underlying connection is going to close it in any way, there > > is no point reading the content. > > > > I intent to address this issue in the documentation for HttpClient once > > HttpClient is upgraded to the next version of HttpCore. > > > > > 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. > > > > I am not entirely sure this is a good idea to make HttpResponse > > responsible for cleanup of such resources. Unless I am missing > > something, it just does not sound right to me. > > > > > > > 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? > > > > > > > I am not much of a writer. I always tend to be too terse with my > > writing. Please do feel free to improve the javadocs and submit the > > changes as a patch. > > > > Cheers > > > > Oleg > > > > > > If it was up to me, I would make HttpMessage extend java.io.Closable say > the following in all subclass javadoc headers. > > #close() must be called when the message is no longer of used to > free up any resources used by this message. > > Would this be possible in a future release? > > James >
That is possible, but would have to wait until 5.0. However, personally, I would rather keep all resource management at the HTTP entity level. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
