You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/11/19 00:17:05 UTC

DO NOT REPLY [Bug 14658] New: - Bad exception handling in getWriter()

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14658>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14658

Bad exception handling in getWriter()

           Summary: Bad exception handling in getWriter()
           Product: Tomcat 4
           Version: 4.1.12
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Connector:Coyote HTTP/1.1
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: erik@bruchez.org


getWriter() seems to be implemented as a PrintWriter. This means that all the
exceptions are eaten. This is due to the fact that PrintWriter does not forward
IOExceptions, but sets an internal variable called "trouble" to true. This
variable is supposed to be cheked with checkError() regularly, but here is is not.

This is bad in particular when writing a large document and the user closes his
browser connection. The servlet will keep writing unaware of the error, and
potentially thousands of exceptions will be caught silently. This can completely
kill a server if many connections are interrupted, because exception handling is
pretty slow.

I tried working around this by casting the Writer to a PrintWriter and calling
checkError() manually, but the PrintWriter is recycled which means that once an
error occurs, all subsequent requests fail.

To solve this, Tomcat should call checkError() and throw an exception or make it
so that the subsequent calls on the writer do not cause so many exceptions to be
thrown and eaten after the first exception is caught. I am fine if those
exceptions are eaten, but the performance hit is unacceptable (some of my
requests that usually complete in a few seconds take over 30 seconds to complete
in this exception-eating mode).

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>