I hesitate to send this message to this list, but I have had no nibbles on the tomcat-user list. As I noted below, I think there may be a bug in the tomcat4 Coyote Connector code that implements flushBuffer(). Can anyone in the Tomcat developer community comment here or point me to someone that "owns" the Coyote connectors?
Thanks in advance, Randy Watler Finali Corporation ------------------------------------------------------------------------ We are using Tomcat to serve pages that can take a long time to generate, (in excess of 1 minute). To prevent the browser from retrying to resend the request, we are committing the request using flushBuffer() immediately after setting the response headers. However, it appears that the CoyoteConnector ServletResponse.flushBuffer() implementation does not execute unless the output stream or writer has been written to. We are currently working around this problem by using chunked encoding and pushing some white space out onto the stream. Of course, this does commit the request, but is ugly. The Servlet 2.3 standard seems to imply that flushBuffer() should commit the request and flush the response headers. Furthermore, the code in tomcat4/CoyoteResponse.java appears to attempt to commit the request and flush the stream. When CoyoteResponse.flushBuffer() invokes OutputBuffer.flush(), it attempts to call OutputBuffer.realWriteBytes(null, 0, 0). This almost calls the necessary doWrite() protocol on the underlying Response object, but the "cnt > 0" argument safety check in OutputBuffer.realWriteBytes():377 prevents it. Is there a bug here or are my eyes missing something subtle, (or obvious)?
