Servlet input/output streams

[Ronald Albury <ro...@gmail.com>]

My understanding is that I should *not* close the servlet input/output
streams (if you don't open them - you shouldn't close them)

But what if I have wrapped those streams inside other streams that I want to
close?  Let's say I have several layers of object streams, cipher streams,
compression streams, etc.  Will it be ok to call close on the outer-most
stream, or do I need to rely on the 'flush' and 'finish' methods on these
wrapping streams.

What about the potential for memory leaks - or is that mostly just an issue
on the inner-most stream that actually does the physical I/O?

Thank you for taking the time to read this email.

Re: Servlet input/output streams

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ronald,

On 6/22/2011 11:23 AM, Ronald Albury wrote:
> My understanding is that I should *not* close the servlet input/output
> streams (if you don't open them - you shouldn't close them)

That seems like good advice.

> But what if I have wrapped those streams inside other streams that I want to
> close?  Let's say I have several layers of object streams, cipher streams,
> compression streams, etc.  Will it be ok to call close on the outer-most
> stream, or do I need to rely on the 'flush' and 'finish' methods on these
> wrapping streams.

Many stream decorators implement the close() method as an internal
operation (digest.doFinal, for example) plus a call to the contained
stream's close() method, resulting in the underlying stream being closed.

The Javadoc for OutputStream.close says "The general contract of close
is that it closes the output stream. A closed stream cannot perform
output operations and cannot be reopened.". That seems like most
decorators should call inner.close() when their close methods are called.

If you are using something like a CipherOutputStream, just make sure
that you have flushed the stream and/or called any other "finish"
methods as appropriate.

> What about the potential for memory leaks - or is that mostly just an issue
> on the inner-most stream that actually does the physical I/O?

Any open stream should be closed at some point. It's the underlying
stream that really consumes resources. As long as your decorator has
flushed everything it had to the underlying stream, it will be GC'd at
some point and you'll be okay.

Let the code that opened the stream also close the stream. Those
decorators aren't going to hurt you.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4DYdoACgkQ9CaO5/Lv0PDyTQCfeG09m8n3ul5bqqUOZZMYZlly
DvYAnivBVP7/gXd+zgV+wD+qn0ITN84M
=4frT
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Servlet input/output streams

[Rehtron <ne...@gmail.com>]

Hi

You may use decorator pattern to decorate the input & output stream from
Servlet to a UnclosableInputStream & UnclosableOutputStream,

public class UnclosableInputStream extends java.io.FilterInputStream {

public UnclosableInputStream(InputStream inputStream) {
super(inputStream);
}

@Override
public void close() {
// do nothing.
}

}

InputStream inputStream = new
UnclosableInputStream(servlet.getInputStream());

inputStream.read(); // invoke the decorated ServletInputStream.
inputStream.close() // do nothing

Hope it'll helpful for you.

Zijian.

2011/6/22 Ronald Albury <ro...@gmail.com>

> My understanding is that I should *not* close the servlet input/output
> streams (if you don't open them - you shouldn't close them)
>
> But what if I have wrapped those streams inside other streams that I want
> to
> close?  Let's say I have several layers of object streams, cipher streams,
> compression streams, etc.  Will it be ok to call close on the outer-most
> stream, or do I need to rely on the 'flush' and 'finish' methods on these
> wrapping streams.
>
> What about the potential for memory leaks - or is that mostly just an issue
> on the inner-most stream that actually does the physical I/O?
>
> Thank you for taking the time to read this email.
>