Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <3DEE483D.9A6CDB90@finali.com>
From: Randy Watler <rwatler@finali.com>
To: tomcat-dev@jakarta.apache.org
Subject: Coyote Connector/Tomcat 4.1.12 flushBuffer()
Date: Wed, 4 Dec 2002 11:23:57 -0700 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C29BC2.501F8980"

------_=_NextPart_001_01C29BC2.501F8980
Content-Type: text/plain;
	charset="iso-8859-1"

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)?


------_=_NextPart_001_01C29BC2.501F8980--