Thanks a lot for checking that. I had already tried that actually and checkError is false. PrintWriter just sets a flag when there is an exception and then that method you reference returns the value of that flag. I set a breakpoint right in that class and it keeps writing with no internal exceptions after the user has cancelled the download on the client-side. So the flag never gets set.
I will try to debug deeper down into the platform. I suppose it is possible there is something else buffering it, but I don't think it is a proxy in my case. Could it be Tomcat itself maybe? In any case, if the consensus is that this has nothing to do with Tomcat (either a code problem or infrastructure issue) I suppose I should try somewhere else. But I really appreciate all the suggestions from this list so far. On Thu, May 20, 2010 at 8:19 PM, Caldarale, Charles R <chuck.caldar...@unisys.com> wrote: >> From: Ðavîd Låndïs [mailto:dlan...@gmail.com] >> Subject: Re: user cancels download attachment >> >> I was hoping Tomcat would have some way of knowing that >> it was cancelled and close it. > > Look at the API spec for PrintStream: "Methods in this class never throw I/O > exceptions". However, you can use the checkError() method to both flush and > see if the stream is still functional. (Note that I haven't tried this in > Tomcat, so I don't know if a one-end-closed socket will return false.) > >> Again, the server continues to write a lot of data -- >> 10+ megs after the user cancels. > > If checkError() doesn't return false (and it's actually fully implemented), > then something (a proxy?) must be buffering the traffic between the server > and the client. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
