Servlet buffering response despite calls to flush()

Question

We have a system where a client makes an HTTP GET request, the system does some processing on the backend, zips the results, and sends it to the client. Since the processing can

Answer 1

You could be getting screwed by the Java API.

Looking through the JavaDocs of the various OutputStream family of classes (OutputStream, ServletOutputStream, FilterOutputStream, and ZipOutputStream) , they either mention that they rely on the underlying stream for flush() or they declare that flush() doesn't do anything (OutputStream).

ZipOutputStream inherits flush() and write() from FilterOutputStream.

From the FilterOutputStream JavaDoc:

The flush method of FilterOutputStream calls the flush method of its underlying output stream.

In the case of ZipOutputStream, it is being wrapped around the stream returned from ServletResponse.getOutputStream() which is a ServletOutputStream. It turns out that ServletOutputStream doesn't implement flush() either, it inherits it from OutputStream which specifically mentions in its JavaDoc:

 flush public void flush()
            throws IOExceptionFlushes 
 this output stream and forces any
 buffered output bytes to be written out. The general contract of flush
 is that calling it is an indication that, if any bytes previously
 written have been buffered by the implementation of the output stream,
 such bytes should immediately be written to their intended
 destination.  If the intended destination of this stream is an
 abstraction provided by the underlying operating system, for example a
 file, then flushing the stream guarantees only that bytes previously
 written to the stream are passed to the operating system for writing;
 it does not guarantee that they are actually written to a physical
 device such as a disk drive. 

  **The flush method of OutputStream does nothing.**

Maybe this is a special case, I don't know. I do know that flush() has been around a long time and it is unlikely that no one has noticed a hole in the functionality there.

It makes me wonder if there is an operating system component to the stream buffering that could be configured to remove the 1k buffer effect.

A related question has a similiar issue but was working directly with a file instead of from a Stream abstraction from Java and this answer points to the MSDN articles involved regarding file buffering and file caching.

A similar scenario was listed in the bug database.

Summary

The Java IO library relies on the OS implementation for Streams. If the OS has caching turned on, Java code may not be able to force a different behavior. In the case of Windows you have to open the file and send non-standard parameters to allow for write-through-cache or no-buffereing functionality. I doubt the Java SDK provides such OS-specific options since they are trying to create platform-generic APIs.