Question

I have a servlet which processes a request for a long time. It suppose to keep doing stuff in the loop inside doPost and send data through response’s out writer. Effectively that continuously appends data in the clients browser . But the problems accures when client just closes the browser. Inspite of the broken connection the response’s writer stream in the servlet never gets closed, thus servlet is unaware of the brocen connection, and keep dumping data into the writer without any errors. How is that posssible? And how do I detect and cancel long request processing in case of browser disconnect?

I thougth checkError() on the response writer should do the trick, but it does not seam to work. Any ideas why?

This is the servlet code which never stops:

protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {    HttpSession session = request.getSession();    System.out.println('Session ' + session.getId() + ' started');     response.setContentType('text/html;charset=UTF-8');     PrintWriter out = response.getWriter();    try    {        while (!out.checkError())        {            try            {                Thread.sleep(1000);            } catch (InterruptedException ex)            {                ex.printStackTrace();            }             Date date = new Date();             // TODO append output to the client browser here            out.println('.....');             System.out.println('Session ' + session.getId() + 'data sent at: ' + date);             out.flush();        //break;  // _TEST        }    } finally    {        System.out.println('Session ' + session.getId() + ' finished');        out.close();    } } 

Thanks,
Mike

Answer 1

The only real way of dealing with this is to have the browser constantly tell you that it’s still there, say every 5-10 seconds. If you go for a minute without hearing anything, you assume the client is gone and forget what you’re doing.

There are several ways to implement this:

• Meta refresh: I don’t like this because it’s disconcerting and obvious for the user;
• An iframe that does that (less obvious); or
• Some AJAX technique, which is probably the best option.

There’s no real way you can detect if the client is still reading what you’re sending. It takes time for TCP connections to die and the path to the client is often indirect anyway (through proxies and so forth) so forget about detecting that.