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