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: Cocoon running modes (was Re: Error Handling is NOT working)
Date Thu, 12 Sep 2002 14:04:08 GMT
Nicola Ken Barozzi wrote:

>
>
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Might be worth investigating into running modes. Hmm.
>>>
>>> But comming back to the original problem ;) - We already have an
>>> intermediate
>>> output stream implemented and noone really complained about it:
>>> Its the buffered output stream in the abstract text serializer...the 
>>> only
>>> problem here is that a) the size of the buffer might be too small
>>> and b) the stream is flushed on recycle().
>>>
>>> So, if we
>>> a) Move this buffered output stream handling out of the serializer
>>>   into the environment and
>>> b) Don't flush the stream on recycling a serializer and
>>> c) Add a small logic checking the buffer size for the current response,
>>>
>>> we have everything we need.
>>>
>>
>> The output stream provided by the servlet engine is already buffered 
>> and we can control the buffer size using 
>> ServletResponse.setBufferSize(). Why do we need an additional buffer ?
>
>
> Because Cocoon is not a servlet; it's mainly used as a servlet, but it 
> is *not* a servlet.
> So regardless to what the servlet container gives us, we must ensure 
> Cocoon gets a neutral set of objects to work on.


I agree that Cocoon is not a servlet, but disagree with your conclusion 
: the environment implementation makes the bridge with the actual 
running environment. In the servlet environment, the Response is just a 
thin wrapper around the HttpServletResponse and the output stream is the 
HttpServletResponse's output stream which *is buffered* by the servlet 
engine, as stated by the servlet spec.

So can't we extend the Environment contract by saying that the output 
stream should be buffered, and providing a new setBufferSize() method ?

This will avoid useless and inefficient double-buffering in servlet 
environment (which is the one mostly used and where perfs and memory are 
critical), and, making the command line environment buffered should be a 
couple of lines in AbstractCommandLineEnvironment.

We can thus have an environment-neutral Cocoon that relies on a buffered 
output stream provided by the environment, regardless what this 
environment is.

>> What about exposing this method by adding it to our Request interface 
>> ? I already proposed this a while ago (see
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101661438030015&w=2), 
>
>
> As I said, we need to expose a facade of the real stream, that is 
> indipendent from the environment implementation used.
>
> Thus we should wrap any stream that is given to Cocoon in a 
> CocoonStream facade, that we can control as you say, and in the 
> servlet case delegate to the servlet container.


Maybe. This can give us more control on methods such as flush and close 
(which, BTW, are already trapped by servlet engines that implement 
persistent connections or chunked responses).

>> including the proposal for setting the buffer size either as a 
>> servlet parameter or an attribute of <map:pipeline>.
>
>
> Definately not in the servlet conf, as a pipeline hint maybe, as a 
> global parameter, surely. 


Don't know. It may be considered as a configuration of the environment, 
and thus given in web.xml for servlet and as a command line argument for 
CLI...

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