On Thu, 2010-04-08 at 15:18 -0400, James Leigh wrote: > On Thu, 2010-04-08 at 20:55 +0200, Oleg Kalnichevski wrote: > > On Thu, 2010-04-08 at 14:18 -0400, James Leigh wrote: > > > Hi all, > > > > > > After looking through the javadocs and the source code it is not clear > > > to me when writeTo is called if consumeContent also needs to be called. > > > > > > > The choice of the method name is very unfortunate. > > HttpEntity#consumeContent should have rather been called > > HttpEntity#dispose or HttpEntity#finish. > > > > Actually the only requirement for proper release of resources held by an > > entity is reading the content stream to the end (until a read operation > > returns -1). So, any of these should be enough: > > > > (1) HttpEntity#consumeContent() > > (2) HttpEntity#writeTo() > > (3) if (HttpEntity#getContent()) > > HttpEntity#getContent().close() > > > > I am really thinking about deprecating HttpEntity#consumeContent > > > > > > > When should the content InputStream get closed? Is the bug in > > > BasicHttpEntity#writeTo or ThrottlingHttpClientHandler and > > > EntitySerializer? > > > > > > > Ideally InputStream returned by HttpEntity#getContent() should always be > > closed. This method will ensure the content is fully consumed and > > resources held by the entity are properly released. > > > > Oleg > > > Thanks for you response Oleg, > > > <rant> > As a Java programmer, I'm not comfortable with *not* calling an > InputStream's close method. I think they should always be closed, even > if read() returns -1, but Sun doesn't make it clear either way. > </rant> >
I'll happily review and apply a patch if you are willing to contribute one ;-) > 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. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org