Historical question about BufferedServletOutputStream.java

[Marc Saegesser <ma...@apropos.com>]

Ever since version 1.1, BufferedServletOutputStream.flush() checks to see if
if the response is using an PrintWriter and if it is it ignores the flush
request.  The question is why?  My guess is that it had something to do with
the fact that the PrintWriter itself has a buffer because it uses an
OutputStreamWriter internally, but that still doesn't make any sense.

The net result is that if a servlet author calls flush on the PrintWriter
returned from response.getWriter() nothing *appears* to happen.  Internally
what happens is that the bytes from the PrintWriter's OutputStreamWriter are
flushed into the BufferedServletOutputStream's buffer, but they aren't sent
to the client.  This is not the behaviour that most servlet authors would
expect and I don't see any reason in the spec that would mandate it.

Does anyone remember or know why BufferedServletOutputStream.flush() does
nothing when a PrintWriter is in use?  There's bug posted against this
behaviour and I don't see any reason why the buffer shouldn't be sent to the
client when a PrintWriter is in use, but before I make a change to something
that's been around for so long I thought I'd see if anyone remembers why it
was done this way to start with.

Re: Historical question about BufferedServletOutputStream.java

[cm...@yahoo.com]

What I remember - it was there, and I never understood very well why :-)

That's one of the reasons I put a lot of time into OutputBuffer and
refactoring the output system.

My best guess was that it is related with higher level code ( Writer,
JspWriter most likely ) that needs to empty it's internal buffers - but
without trigering a real write. 

For example if a jsp includes a servlet, it must empty the JspWriter
buffers to prevent out-of-order output. Until recently jasper used
flush() to do that ( it has been fixed with a cast to JspWriterImpl ). It
may be possible to have the servlet included by the jsp forward to another
page - a valid sequence that will not work if the flush commits the
answer, so the flush had to be avoided. 

Working with streams can be extremely confusing, especially in situations
like this. 

If you want to fix this - the jasper side was fixed wrt. flush() ( at
least in 3.3), but you need to be carefull.

Costin
 



On Thu, 21 Jun 2001, Marc Saegesser wrote:

> Ever since version 1.1, BufferedServletOutputStream.flush() checks to see if
> if the response is using an PrintWriter and if it is it ignores the flush
> request.  The question is why?  My guess is that it had something to do with
> the fact that the PrintWriter itself has a buffer because it uses an
> OutputStreamWriter internally, but that still doesn't make any sense.
> 
> The net result is that if a servlet author calls flush on the PrintWriter
> returned from response.getWriter() nothing *appears* to happen.  Internally
> what happens is that the bytes from the PrintWriter's OutputStreamWriter are
> flushed into the BufferedServletOutputStream's buffer, but they aren't sent
> to the client.  This is not the behaviour that most servlet authors would
> expect and I don't see any reason in the spec that would mandate it.
> 
> Does anyone remember or know why BufferedServletOutputStream.flush() does
> nothing when a PrintWriter is in use?  There's bug posted against this
> behaviour and I don't see any reason why the buffer shouldn't be sent to the
> client when a PrintWriter is in use, but before I make a change to something
> that's been around for so long I thought I'd see if anyone remembers why it
> was done this way to start with.
> 
> 
>