On Tuesday, Aug 10, 2004, at 18:41 America/New_York, Bill Barker wrote:
spec-quote version=servlet 2.4 section=14.2.22
Sets the preferred buffer size for the body of the response. The
servlet
container will use a buffer at least as large as the size requested.
The
actual buffer size used can be found using getBufferSize.
/spec-quote
Yah, I was aware of that. So it doesn't violate the spec, but does
that mean that there is no way to set the actual bufferSize less than
8K in Tomcat? This is beneficial in some scenarios. For us, we have
some cases where dynamic content produced via Servlet is expensive to
create. It is highly preferable to begin streaming content back to the
client as soon as possible. For example, some meta info followed by
expanded info. The tomcat configuration docs mention socketBuffer for
the HTTP Connector.
quote
The size (in bytes) of the buffer to be provided for socket output
buffering. -1 can be specified to disable the use of a buffer. By
default, a buffers of 9000 bytes will be used.
/quote
If I didn't know better, I would think(and did) that this is the Tomcat
specific mechanism to ensure that if I had set a smaller bufferSize in
my response, and an equally small value here, that the content would be
flushed to the client. I guess what I'm really concerned with is if
there is any good reason for explicitly preventing a small bufferSize?
I guess another alternative is to fluff up the response with commented
text to generate 8K of content before the more expensive stuff starts.
-lenny
- Original Message -
From: Lenny Marks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 10, 2004 3:31 PM
Subject: Tomcat 5; can't set response bufferSize 8K
It seams it is impossible to set the response buffer
size(response.setBufferSize) with anything less than 8K. That is,
response.getBufferSize() still returns 8K. Anything over 8K does work.
I downloaded the source and pinned it down to the following:
In org.apache.coyote.tomcat5.CoyoteResponse an outputBuffer is
initialized with 'new OutputBuffer()'. The default constructor of
OutputBuffer then internally creates a new ByteChunk with a 'limit' of
DEFAULT_BUFFER_SIZE, which is 8K.
In CoyoteResponse setBufferSize is:
public void setBufferSize(int size) {
if (isCommitted() || !outputBuffer.isNew())
throw new IllegalStateException
(sm.getString(coyoteResponse.setBufferSize.ise));
outputBuffer.setBufferSize(size);
}
and OutputBuffer.setBufferSize is:
public void setBufferSize(int size) {
if (size bb.getLimit()) {// ??
bb.setLimit(size);
}
}
The result is that the buffer size can never be set less than
OutputBuffer.DEFAULT_BUFFER_SIZE or 8K.
Is there any good reason for this? The question marks make me wonder.
For now I just changed the DEFAULT_BUFFER_SIZE to 1K. Also, I'm not
sure how this is related to bufferSize and socketBuffer for the
HTTP1.1
Connector. I sounds like bufferSize is related to reading the request.
Should it be that socketBuffer is the default bufferSize for a
response?
BTW, I had done a lot of searching on this issue. I didn't find any
related bugs or postings on the Tomcat mailing lists. I had come
across
one or two postings on various other lists from people having the same
problem, but the threads were never answered. I myself, am new to this
list.
Thanks in advance for any advice,
-lenny
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This message is intended only for the use of the person(s) listed
above as the intended recipient(s), and may contain information that
is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us
immediately by e-mail and then delete all copies of this message and
any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail
sent through the Internet is not secure. Do not send confidential or
sensitive information, such as social security numbers, account
numbers, personal identification numbers and passwords, to us via
ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
