One of the most useful features added in version 2.2 of the servlet API is response buffering. A servlet now has control over whether the server buffers its response, and may dictate how large a buffer the server can use.
In previous versions of the API, most Web servers implemented response buffering as a way to improve performance. Exactly how large that buffer was depended on the server. Generally, servers had buffers in the neighborhood of 8 KB.
The important change for 2.2 is that a servlet now can specify a minimum buffer size for its output. This improves the flexibility of servlet error handling.
How does this work? Well, the structure of HTTP dictates that the first line of an HTTP response includes a status code indicating the success or failure of the client request. To be sure to correctly set the status code, servlets have had to do full error checking before generating any output. If an error was encountered halfway through the response, it was just too bad. The response was already sent (or committed) and the status code and headers could not be changed.
A response buffer allows a servlet to write some amount of output with a guarantee that the response won't be immediately committed. If the servlet finds an error, the status code and headers can still be changed so long as the buffer has not been flushed.
Sets the preferred buffer size for the body of the response. The servlet container will use a buffer at least as large as the size requested. The actual buffer size used can be found using getBufferSize.
A larger buffer allows more content to be written before anything is actually sent, thus providing the servlet with more time to set appropriate status codes and headers. A smaller buffer decreases server memory load and allows the client to start receiving data more quickly.
This method must be called before any response body content is written; if content has been written, this method throws an IllegalStateException.
another way to set buffer