Question

i tested HttpResponse#flushBuffer and PrintWriter#flush on Tomcat 7 below, but it seemed that the response rather ignored them than flushed the content over the wire asap as expected.

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet("/HelloServlet")
public class HelloServlet extends HttpServlet {

    private static final long serialVersionUID = 1L;

    protected void doGet(HttpServletRequest request,
            HttpServletResponse response) throws ServletException, IOException {

        PrintWriter pw = response.getWriter();
        pw.println("say hi now");
        pw.flush();
        response.flushBuffer();
        try {
            Thread.sleep(5000);
        } catch (Exception e) {
        }
        pw.println("say bye in 5 seconds");

    }

}

The brower displayed “hi” and “bye” together after the delay. Is it a misbehavior or intended?

@EDIT

According to @Tomasz Nurkiewicz‘s suggestion, i tested again with curl then the issue was gone. It seems that standard browsers and tcp/ip monitor pack small pieces of contents from the same http response to render them together.

@EDIT 2

It’s also observed that both HttpResponse#flushBuffer and PrintWriter#flush drive Tomcat 7 to send the client chunked data.

Answer 1

The API for flushBuffer() is very precise:

Forces any content in the buffer to be written to the client. A call to this method automatically commits the response, meaning the status code and headers will be written.

So either Tomcat is not implemented according to the spec (buffers more aggressively and holds flushes if they are too small) or the client (browser) waits for more input before actually rendering it.

Can you try with curl or nc instead?