Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

res.flushBuffer() vs res.getOutputStream().flush();

What's the difference between calling :

res.flushBuffer();

versus

res.getOutputStream().flush();  

Do these methods flush the same buffer ?

If so, can you give me a clue on how this buffer is managed by the servlet container?

like image 457
GionJh Avatar asked Nov 10 '12 00:11

GionJh


2 Answers

They would flush the same buffer if you have been using getOutputStream to write to the body. The other alternative is getWriter for non-binary data. If you had been using that, then calling res.getOutputStream().flush(); probably wouldn't work.

The way the buffer is managed is implementation-specific but take one of the Tomcat implementations for example. You can see that there are some fields like this:

/**
 * The associated output buffer.
 */
protected OutputBuffer outputBuffer;
/**
 * The associated output stream.
 */
protected CoyoteOutputStream outputStream;
/**
 * The associated writer.
 */
protected CoyoteWriter writer;

Calling getOutputStream() creates a CoyoteOutputStream that uses the outputBuffer field that is shown there and likewise for getWriter(). So they both would use that outputBuffer depending on which you use. flushBuffer simply does this:

@Override
public void flushBuffer()
    throws IOException {
    outputBuffer.flush();
}
like image 68
Dave L. Avatar answered Sep 21 '22 17:09

Dave L.


What's the difference between calling ...

The only significant difference is that the first version will work whether you are writing / going to write the body in text or binary mode, whereas the second version only works with binary mode output.

Do these methods flush the same buffer ?

Since the javadocs don't give an explicit answer, technically it is implementation dependent. However, in practice the answer is probably "YES" for most implementations, because it is hard to conceive of it making sense to have separate buffers.

There is some indirect evidence for this in the javadoc:

  • The javadoc for setBufferSize(int) says: "Sets the preferred buffer size for the body of the response." The implication is that this buffer is the same "the buffer" referred to in the javadoc for flushBuffer().

  • The javadoc for flushBuffer() says: "A call to this method automatically commits the response, meaning the status code and headers will be written." ... which is consistent with a model where there is effectively one buffer for everything.

The other thing to note that the response object that a servlet sees could actually be an application specific wrapper that was inserted further up the filter chain. It is possible for such a wrapper to behave in a way that is inconsistent with what the javadoc (and the rest of the servlet spec) says.


If so, can you give me a clue on how this buffer is managed by the servlet container?

Your best bet is to look at the source code of the container.

like image 36
Stephen C Avatar answered Sep 21 '22 17:09

Stephen C