On Tuesday, Aug 10, 2004, at 18:41 America/New_York, Bill Barker wrote:
<spec-quote version="servlet 2.4" section="14.2.22">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.
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>
<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]
