cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [jira] Commented: (COCOON-1658) Somewhere output is held...
Date Wed, 26 Oct 2005 18:58:58 GMT
On 26 Oct 2005, at 17:49, Carsten Ziegeler wrote:
> Vadim Gritsenko (JIRA) wrote:
>>     [ 
>> page=comments#action_12355965 ]
>> Vadim Gritsenko commented on COCOON-1658:
>> -----------------------------------------
>> (where is reply button in jira?)
>>> So, my question is why is the buffer right now set to "unlimited"?
>>> Is there any specific caveat for this?
>> If you are using caching pipeline then complete response will have  
>> to be buffered
>> in any case. For non caching pipelines, complete response will have
>> to be buffered if serializer requires content length to be set.
>> For all other cases...
> The only reason for "unlimited" is error handling. If an error happens
> when some content has already been streamed to the client, we can't  
> roll
> back the already streamed part. Without buffering you would get
> corrupted pages. So if you're sure that you don't have exceptions  
> during
> streaming, you can turn off buffering.
> We decided a long time ago, to set the default to "unlimited" just for
> making error handling work in all cases.
> If the caching pipeline is used and in the case the serializer  
> needs to
> set the content length, then the pipeline takes care about buffering.


>> I think this outputBuffer is not really needed.
> I think this is another example of running modes. During  
> development you
> might want to have an unlimited buffer while in production (where  
> never
> an error occurs :) ) you can disable it.

Sorry, I'm a moron...

For some reason I've never seen that it's extremely well documented  
in the Cocoon default sitemap.

            | If not specified, the value of the outputBufferSize  
parameter is -1.
            | This will cause Cocoon to buffer all output until  
processing has finished
            | before sending it to the client. This has the advantage  
that in case
            | an error occurs during the processing of the SAX- 
pipeline, Cocoon is still
            | able to reset the response and send an error page  
instead. Otherwise the
            | error page will be appended to the output already send  
to the client.
            | If you are generating larger pages, it might be  
benificial to enable
            | this parameter, so that output is gradually send to the  
client as it
            | is being generated.
            | For more granularity, you can also supply this  
parameter to
            | individual map:pipeline elements (using map:parameter  


View raw message