Servlets: ServletOutputStream To close or not to Close?
3,463 views
Skip to first unread message
Brian
May 25, 2009, 8:21:32 AM5/25/09
to The Java Posse
It seems about a 50/50 split in hello world examples of HttpServlet
out on the 'internets' as to whether or not to close the
ServletOutputStream or PrintWriter. NetBeans for example will put the
close() call in their new Servlet wizard by default. So does Oracle's
JDeveloper. But other tutorials/examples do not close it.
http://edocs.bea.com/wls/docs70/servlet/progtasks.html
In my particular case not closing the ServletOutputStream solved an
'odd behavior' bug in an application when running on HTTPS on a
somewhat 'black box' production environment that was using Oracle Web
Cache and several other pre and post processing technologies on each
request. But I have not been successful at articulating why not
closing the outputstream is the fix or verifying there are no other
consequences as a result of not closing the output stream. 99% of the
time it seems to matter little whether the close is there are not (e.g
every J2EE IDE I have tried), but in this case it did Any thoughts?
public class HelloWorldServlet extends HttpServlet {
public void service(HttpServletRequest req,
HttpServletResponse res)
throws IOException
{
// Must set the content type first
res.setContentType("text/html");
// Now obtain a PrintWriter to insert HTML into
PrintWriter out = res.getWriter();
out.println("<html><head><title>" +
"Hello World!</title></head>");
out.println("<body><h1>Hello World!</h1></body></html>");
//QUESTION: close or not close:
//out.close();
}
}
out on the 'internets' as to whether or not to close the
ServletOutputStream or PrintWriter. NetBeans for example will put the
close() call in their new Servlet wizard by default. So does Oracle's
JDeveloper. But other tutorials/examples do not close it.
http://edocs.bea.com/wls/docs70/servlet/progtasks.html
In my particular case not closing the ServletOutputStream solved an
'odd behavior' bug in an application when running on HTTPS on a
somewhat 'black box' production environment that was using Oracle Web
Cache and several other pre and post processing technologies on each
request. But I have not been successful at articulating why not
closing the outputstream is the fix or verifying there are no other
consequences as a result of not closing the output stream. 99% of the
time it seems to matter little whether the close is there are not (e.g
every J2EE IDE I have tried), but in this case it did Any thoughts?
public class HelloWorldServlet extends HttpServlet {
public void service(HttpServletRequest req,
HttpServletResponse res)
throws IOException
{
// Must set the content type first
res.setContentType("text/html");
// Now obtain a PrintWriter to insert HTML into
PrintWriter out = res.getWriter();
out.println("<html><head><title>" +
"Hello World!</title></head>");
out.println("<body><h1>Hello World!</h1></body></html>");
//QUESTION: close or not close:
//out.close();
}
}
Viktor Klang
May 25, 2009, 9:05:53 AM5/25/09
to java...@googlegroups.com
I say: Don't close.
The lifecycle of the request is up to the container to manage.
(and also, it could potentially damage Filters processing what's produced by the Servlet)
Just my 2 cents,
--
Viktor Klang
Rockstar Developer
Casper Bang
May 25, 2009, 10:01:51 AM5/25/09
to The Java Posse
Joshua Bloch taught us to use these explicit termination methods. The
tricky things is, its unclear whether getWriter actually opens a
stream or is simply an accessor/property to one. I admit to always
closing it explicitly, since a second call to getWriter usually
results in "java.lang.IllegalStateException: getWriter() has already
been called" suggesting I was the one who opened it. Certainly I would
expect filter chain hooks beneath to simply override close() in a
normal decorator fashion and do their post-processing? Perhaps this is
container specific and an ugly corner of the Servlet API.
/Casper
On May 25, 2:21 pm, Brian <brian.hart.w...@gmail.com> wrote:
> It seems about a 50/50 split in hello world examples of HttpServlet
> out on the 'internets' as to whether or not to close the
> ServletOutputStream or PrintWriter. NetBeans for example will put the
> close() call in their new Servlet wizard by default. So does Oracle's
> JDeveloper. But other tutorials/examples do not close it.http://edocs.bea.com/wls/docs70/servlet/progtasks.html
tricky things is, its unclear whether getWriter actually opens a
stream or is simply an accessor/property to one. I admit to always
closing it explicitly, since a second call to getWriter usually
results in "java.lang.IllegalStateException: getWriter() has already
been called" suggesting I was the one who opened it. Certainly I would
expect filter chain hooks beneath to simply override close() in a
normal decorator fashion and do their post-processing? Perhaps this is
container specific and an ugly corner of the Servlet API.
/Casper
On May 25, 2:21 pm, Brian <brian.hart.w...@gmail.com> wrote:
> It seems about a 50/50 split in hello world examples of HttpServlet
> out on the 'internets' as to whether or not to close the
> ServletOutputStream or PrintWriter. NetBeans for example will put the
> close() call in their new Servlet wizard by default. So does Oracle's
Viktor Klang
May 25, 2009, 12:04:04 PM5/25/09
to java...@googlegroups.com
Casper, don't get me started on the getWriter travesty...
If it'd been createWriter() I'd agree to close it, but the whole Http-
part of Servlets is malnourished.
So I guess I'm still in the Let-the-container-manage-it camp
Viktor,
Development Black Ops
If it'd been createWriter() I'd agree to close it, but the whole Http-
part of Servlets is malnourished.
So I guess I'm still in the Let-the-container-manage-it camp
Viktor,
Development Black Ops
Christian Catchpole
May 25, 2009, 6:12:17 PM5/25/09
to The Java Posse
My expectation would be to close() as it should be abstracted from any
real IO stream and closing should do no harm. In fact there can be
cases where harm is done if you don't close, or at least flush. I
wrote a method to wrap the OutputStream with a compressing stream if
the client would accept it. This would be the same for any buffered
stream that you wrap around the OutputStream. You will have to flush
it as the container closing the stream it handed you is not going to
flush your wrapper stream. And a close is as good as a flush.
I do accept that I've often never closed on non-wrapped streams and
it's done no harm.
As for Brian's case, I would expect that closing the stream has "gone
too far" closing some underlying stream prematurely.
real IO stream and closing should do no harm. In fact there can be
cases where harm is done if you don't close, or at least flush. I
wrote a method to wrap the OutputStream with a compressing stream if
the client would accept it. This would be the same for any buffered
stream that you wrap around the OutputStream. You will have to flush
it as the container closing the stream it handed you is not going to
flush your wrapper stream. And a close is as good as a flush.
I do accept that I've often never closed on non-wrapped streams and
it's done no harm.
As for Brian's case, I would expect that closing the stream has "gone
too far" closing some underlying stream prematurely.
Viktor Klang
May 25, 2009, 6:16:26 PM5/25/09
to java...@googlegroups.com
I'd agree that flushing is a rather good practice, and while one's at it, the mrs' generally appreciate having the toilet seat lid down.
Michael Neale
May 25, 2009, 7:37:54 PM5/25/09
to The Java Posse
You know it has been many years, but I still find that joke funny -
everytime I write "flush()" I have a little smile.
everytime I write "flush()" I have a little smile.
Reinier Zwitserloot
May 25, 2009, 11:30:51 PM5/25/09
to The Java Posse
IIRC, when you close a Servlet, the ServletIn/OutputStreams get closed
for you as well. However, that's not good enough if you're wrapping
those into a non-direct-writethrough stream, such as GzipOutputStream,
as Christian Catchpole mentioned.
Therefore, close em. Be aware that the close calls, especially on the
ServletOutputStream, can generate exceptions; the servlet container
and the network can both simply be buffering your output, and the close
() then exceptions when the resulting flush down the pipe runs into an
I/O issue. Remember the mantra:
InputStream.close(): stupid.
OutputStream.close(): Even more important that .write()'s IOExceptions
- assume the entire write operation failed if you get one.
for you as well. However, that's not good enough if you're wrapping
those into a non-direct-writethrough stream, such as GzipOutputStream,
as Christian Catchpole mentioned.
Therefore, close em. Be aware that the close calls, especially on the
ServletOutputStream, can generate exceptions; the servlet container
and the network can both simply be buffering your output, and the close
() then exceptions when the resulting flush down the pipe runs into an
I/O issue. Remember the mantra:
InputStream.close(): stupid.
OutputStream.close(): Even more important that .write()'s IOExceptions
- assume the entire write operation failed if you get one.
Jess Holle
May 26, 2009, 7:17:28 AM5/26/09
to java...@googlegroups.com
Having written my own response compression filter, I'd have to say that
it is a mistake to rely upon anyone (other than the container) calling
close on the output. You should allow for it, but not rely upon it.
Brian
May 8, 2013, 2:17:54 PM5/8/13
to java...@googlegroups.com
It has been almost 4 years since I posted this, but it is never too late to say thank you for all the discussion on this thread. I just happen to reference this with a colleague who was dealing with this IE specific issue and how it let me to post this question.
Reply all
Reply to author
Forward
0 new messages