Re: [jira] Commented: (COCOON-1658) Somewhere output is held...

[Pier Fumagalli]

On 26 Oct 2005, at 17:49, Carsten Ziegeler wrote:

Vadim Gritsenko (JIRA) wrote:

[ http://issues.apache.org/jira/browse/COCOON-1658? 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?

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...

If you are using caching pipeline then complete response will have to be buffered

The only reason for "unlimited" is error handling. If an error happens

back the already streamed part. Without buffering you would get

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.


set the content length, then the pipeline takes care about buffering.

when some content has already been streamed to the client, we can't roll corrupted pages. So if you're sure that you don't have exceptions during If the caching pipeline is used and in the case the serializer needs to

Aaaaahhhhhhhhhhh!!!!!!!

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...



       <!--+

           | is being generated.

           +-->

    Pier

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 | For more granularity, you can also supply this parameter to | individual map:pipeline elements (using map:parameter syntax).

smime.p7s
Description: S/MIME cryptographic signature