cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Error Handling is NOT working
Date Wed, 11 Sep 2002 13:45:18 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>  
>
>>Ivelin Ivanov wrote:
>>
>>    
>>
>>>----- Original Message -----
>>>From: "Sylvain Wallez" <sylvain.wallez@anyware-tech.com>
>>>To: <cocoon-dev@xml.apache.org>
>>>Sent: Wednesday, September 11, 2002 8:01 AM
>>>Subject: Re: Error Handling is NOT working
>>>
>>>
>>>      
>>>
>>>>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.
>>>>
>>>>
>>>>        
>>>>
>>>Agreed. The sitemap interpreter should flush the output stream when it's
>>>done interpreting a request.
>>>
>>>
>>>      
>>>
>>[Picky mode on]
>>
>>Nope. Read carefully : "the responsibility of the *pipeline*" ! The
>>sitemap responsibility is to build the pipeline by executing the sitemap
>>instructions. The interpreter never touches the output stream : it gives
>>the Environment object to the pipeline, and this is where the pipeline
>>gets the stream.
>>
>>    
>>
>
>I agree that it's the responsibility of the environment (or servlet) to
>flush and close the output stream - but you can't prevent someone from
>doing this.
>
>And yes, increasing the buffer size would eliminate an intermediate stream,
>if the size is big enough!
>
>We are always talking of "a user friendly Cocoon" and this here is such a
>point:
>The problem can be solved by a configurable parameter for the buffer size
>of the output stream. But this requires knowledge of this parameter and how
>to configure it.
>A user friendly system should be able to work as expected without changing
>configuration parameters.
>

I fully agree with you. However, there are some places where some manual 
tuning is required since automatic handling is too costly. Think for 
example to the pool sizes, which is IMO a much more difficult and 
critical problem.

But we can do something to help the user : when an error occurs, we try 
to reset the output buffer (see HttpEnvironment.tryResetResponse()). A 
more explicit message logged there when the response couldn't be reset, 
inviting the user to increase the buffer size.

Also, a nice "what should I do when output and error are intermixed on 
screen" FAQ could also to the trick...

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message