Carsten Ziegeler wrote: >Hi, > >I just have to repeat an email I wrote over a year ago, because the >problem is getting worse: > >If an error occurs in the pipeline, the error handler is called and >produces some output (or a response). At this time, the original >pipeline could have already output some information and you might >get an "response already committed" exception or something like that. > >Ok, so far so good, but since some time a serializer flushed the output >stream when it is recycled...so the response is always already committed >and the output stream can't be reset - and when the error handler trys >to create its output, an exception is thrown! > >
Why does have a serializer to flush its output when it is recycled ? Flushing (and output stream management) is IMO the responsibility of the pipeline, and not that of the serializer. >If we want to keep this error handler stuff I still vote for an >intermediate output stream for the normal pipeline. This output stream >"is copied" to the real output stream only if no error occurs. >This is some extra performance cost - so we could make this somewhere >configurable. > Wow ! As you say, this is an important extra cost for exceptional conditions. I would prefer serializers not flushing and increasing the buffer size (using a new servlet parameter ?). >If anyone has a different solution, I'm all ears - but the current >implementation is absolutely useless. > > A quick grep shows that only AbstractTextSerializer flushes in its recycle(). The fix seems easy. 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]
