-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org