i just happened to notice that the behaviour of tomcat 4 response buffers
might not be as expected with respect to buffer size. below is some code
from org/apache/catalina/connector/ResponseBase.java:
--- snip ---
public void write(byte b[], int off, int len) throws IOException {
if (suspended)
throw new IOException
(sm.getString("responseBase.write.suspended"));
// If the whole thing fits in the buffer, just put it there
if (len == 0)
return;
if (len <= (buffer.length - bufferCount)) {
System.arraycopy(b, off, buffer, bufferCount, len);
bufferCount += len;
contentCount += len;
return;
}
// Flush the buffer and start writing full-buffer-size chunks
flushBuffer();
int iterations = len / buffer.length;
int leftoverStart = iterations * buffer.length;
int leftoverLen = len - leftoverStart;
for (int i = 0; i < iterations; i++)
write(b, off + (i * buffer.length), buffer.length);
// Write the remainder (guaranteed to fit in the buffer)
if (leftoverLen > 0)
write(b, off + leftoverStart, leftoverLen);
--- end snip ---
it looks like when you are writing to a response, and the size of the new
chunk of data + the size of the existing data in the buffer is greater than
the buffer size, the existing data will be written to the client, then the
new data will be added to the buffer and all or part of it possibly written
to the client.
it may not make much of a difference, but i would have expected the internal
buffer to be completely filled before data is sent to the client.
for example, suppose your buffer size is 8K. if you write 1 byte to the
response, then write 8K to the response, first 1 byte will be written to the
client, then 8K will be written to the client. i would have expected this
to be the other way around.
probably not a big deal, just thought i'd point it out :)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
