My test confirms what I believe Andy reports. I was running Tomcat standalone, whereas Andy is running it behind HTTPD.

Here is my code, if anyone is interested:

/* Testing a question raised by Andy Oliver, 3/29/3:
How to regain control in a servlet when writing to the
outputStream is blocked.  This test does not find an
answer, and rather confirms what Andy discovered.

The output stream is not closed when ordered so in
StreamTimeout.run().  Rather output continues merrily
along till the loop in doPost() finishes.
*/

import javax.servlet.http.*;
import java.io.*;
import javax.servlet.*;

public class StopTester extends HttpServlet{

  public void doPost(HttpServletRequest req,
        HttpServletResponse res) throws IOException{

    res.setContentType("text/html");
    ServletOutputStream outStream = res.getOutputStream();

    outStream.print("<HTML><BODY>Starting ... ");
    StreamTimeout timeOutThread =
              new StreamTimeout(4, outStream);
    timeOutThread.start();
    for (int i = 0; i < 8; i++){
      try{Thread.sleep(1000);}
      catch (InterruptedException e){};
      try{
        outStream.print("<br>  count " + i);
      }
      catch(IOException e){
        System.out.println("IOException on count " +
                         i + ". " + e.toString());
        break;
      }
      System.out.println("Hey, I just wrote: "+i);
    }

    outStream.print("<br>done</Body></html>");
    System.out.println("Done and gone out of here");
    outStream.close();
  }// method doPost

  class StreamTimeout extends Thread{
    int breakDelay;
    OutputStream outputStream;
    StreamTimeout(int breakAfterSeconds, OutputStream os){
      breakDelay = breakAfterSeconds;
      outputStream = os;
    }
    public void run(){
      try{
        sleep(breakDelay*1000);
        outputStream.close();
        System.out.println("closed the OutputStream");
      }
      catch (Exception e){
        System.out.println("Exception in run(): "+
                     e.toString());
      }
    }
  }//inner class StreamTimeout
}




Andrew C. Oliver wrote:
Okay so what I discovered is that the connection doesn't close if you have HTTPD in front of Tomcat until the connection timeout for the connector. The nasty thing is that I'm still using the abandoned ModWebapps (which was great but Pier decided to abdicate), so the connection timeout is not configurable.

Therefore no IOException is ever generated! I tried anyhow with a little reaper thread to close the connection but its not being activated because as far as it knows, everything is rosey.

Conrad F. D'Cruz wrote:
You could buffer the data and write it out in chunks ... testing in between
writes by flush(). If the stream has been closed by a broken client
connection you will get an IOException.


Conrad

"Andrew C. Oliver" wrote:
I guess if I open up a reaper thread I could do that.. . I can't very
well close the stream if I'm blocked on the write call  (hence the
bind)..  I would rather not open up a thread to do that, but I guess I
can if I have to.

-Andy

Richard O. Hammer wrote:
Andy,

I think this might work.
It appears to me that you can call close() on the ServletOutputStream.
I believe that will cause your write() on the ServletOutputStream
(which was blocked) to throw an IOException.

If you set a boolean breakoffOrdered = true, before you close the
stream, then when you catch the IOException you can test if
breakoffOrdered, and act accordingly.


_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://trijug.org/mailman/listinfo/juglist_trijug.org

Reply via email to