On Tue, 8 Oct 2002, Galbreath, Mark wrote: > Interesting test...Milt, what's your opinion on this. Good effort, > in any event!
Hey, don't get me involved in this! (FWIW, I don't have a definitive answer, but I believe from past discussions that it's not always possible to catch this situation -- in fact, it may usually not be possible -- as Michael's test suggests. Not sure how you'd deal with this on an application basis, if this were so important. But I do note that at web shopping sites, when you're on that final page about to buy something, they often seem to have verbiage to the effect of "As soon as you press the button, your purchase is complete" :-). > -----Original Message----- > From: Michael Peceny [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 08, 2002 7:31 AM > > Not quite -- the client and the server are playing a "request-response > game", and when one of the two suddenly quits in the middle of the game, the > other should realize this... > > I could imagine that once the client stops waiting for the response (i.e., > the user hits the cancel button), there is an error on the server when it > attempts to send response data to the client (or is this indistinguishable > from the response data being lost/bogged down somewhere on the net? what > does the client do when the server attempts to send it some response data it > has stopped waiting for? does it send a "don't want your (from my point of > view unrequested) data" back the server?) ... and on to an answer (derived > from a simple test, so it's not necessarily comprehensive or true without > exception): > > ok, tested it, and actually there is an exception thrown when the client has > stopped listening. BUT... that exception isn't thrown within the servlet's > doGet() / doPost (), but rather by the servlet engine afterwards. > > Example: > > public void doPost( HttpServletRequest request, HttpServletResponse response > ) > throws ServletException, IOException > { > response.setContentType( "text/plain" ); > PrintWriter out = response.getWriter(); > > try { > out.write( "Line 1\n\r" ); > > // set a breakpoint here and, while the debugger is halted, click on > the > // browser's STOP/CANCEL button > > out.write( "Line 2" ); > out.flush(); > response.flushBuffer(); > // hmm... apparently, the servlet doesn't get told whether the data that is > flushed > // is accepted by the client or not > } catch ( Exception e ) { > System.err.println( "Exception: " + e.toString() ); > } > > return; > } > > The catch block doesn't get an exception. But after doPost() is left, the > servlet engine (New Atlanta ServletExec Debugger) reports the following: > > Responder.run() caught an IOException 1:Connection reset by peer: socket > write error Most likely the user broke the connection by stopping the > browser. > > So, an exception is actually thrown, the server does realize that the client > isn't listening any more (it doesn't tell the servlet, though). But > unfortunately we cannot handle it inside the doPost() method. > > ___________________________________________________________________________ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > Milt Epstein Research Programmer Integration and Software Engineering (ISE) Campus Information Technologies and Educational Services (CITES) University of Illinois at Urbana-Champaign (UIUC) [EMAIL PROTECTED] ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html