> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] > > Vadim Gritsenko wrote: > > >>From: Jeremy Quinn [mailto:[EMAIL PROTECTED]] > >> > <snip/> > > >This means: Hold stream till end-of-processing. This allows: reset > >response completely, and output clean error page, without parts of XML > >previously processed. > > > >>If an internal pipeline makes an error, and has it's own > >>error-handler, I would hope that error could be inline, > >> > > > >Then the pipeline which called this internal one will never know that > >exception happened: it will get either result, or partial result and > >error (IIRC). > > > > Yep : <handle-errors> isn't executed on internal request.
Hm. I forgot this one... Then it should be rephrased to "... it will get either result, or exception". > >Try also increasing buffer of the serializer, then environment will be > >able to reset the partial result and output clean error page. From the > >Environment: > > > <snip/> > > tryResetResponse() has unfortunately nothing to do with serializer > buffering : it is directly tied to the servlet engine's ouputstream > buffering. And serializer's buffer indirectly tied to the servlet engine's ouputstream: if serializer does not flushes its buffer, servlet engine's ouputstream is empty, and it means that it definitely is not commited. Did I miss something here? > This methods checks if response.isCommitted(), meaning some > data was sent to the client, and if not, calls response.reset(), which > empties the servlet engine's buffer. > > So a solution to your problem, Jeremy, may be to increase the response > buffer. javax.servlet.ServletResponse allows this through > setBufferSize(), but this method doesn't exist on > cocoon.environment.Response. > > There are IMO two ways to set this value in Cocoon : > - add a new "buffer-size" parameter in web.xml : it will be then set for > *all* requests, but having a global setting may be overkill for most request -0. I agree with "overkill". > - enhance <map:pipeline> with a "buffer-size" attribute, which allows > fine-grained control of the buffer size at the pipeline level. This > implies we add setBufferSize to cocoon's Request interface. setBufferSize could be invoked from the Action or XSP. Not sure that it is needed on the pipeline though. +1 on adding to the Request. > Wether we chose one or the other (or something else), I suggest to do it > after 2.0.2. > > There are also some related subjects that were left pending that could > be discussed at that time : > - per-pipeline choice of the pipeline implementation, e.g. <map:pipeline > type="caching"> This one is todo already. > - enhancement of <handle-errors> : having only types 404 and 500 and > rather limiting, while a Notifying gives us an interesting "type" > information that could be used to select a particular error handler. Have nothing against. > Thoughts ? PS Why do we need this double buffering in the first place (thinking about serializer's buffer)? Vadim > Sylvain > > -- > Sylvain Wallez > Anyware Technologies Apache Cocoon > http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
