tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lenny Marks <>
Subject Re: Tomcat 5; can't set response bufferSize < 8K
Date Wed, 11 Aug 2004 00:28:37 GMT

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.

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.

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.


> ----- Original Message -----
> From: "Lenny Marks" <>
> To: <>
> 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:
>> For additional commands, e-mail:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message