cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <peter.hunsber...@gmail.com>
Subject Re: Avoiding OutOfMemory Errors by limiting data in pipeline
Date Mon, 12 May 2008 14:58:48 GMT
On Sun, May 11, 2008 at 6:59 PM, Joerg Heinicke <joerg.heinicke@gmx.de> wrote:
> On 09.05.2008 09:41, Peter Hunsberger wrote:
>
>
> >
> > I haven't looked at the code here, but couldn't you just introduce a
> > second getOutputStream( int bufferSize ) method where the current
> > interface method continues with the current default logic if it is
> > used?
> >
>
>  getOutputStream() actually already takes an int parameter, the flush buffer
> size.

Yeah, I saw that...

> Whether to add another getOutputStream() method or modify the existing
> one there is not really a difference IMO. Environment is a kind of internal
> interface (or SPI how it used to be called lately, isn't it?). This means
> there should be only very few implementations besides the one we provide if
> at all (Forrest, Lenya, CLI environment?). And in Cocoon we would change all
> usages of the single-parameterized method to the one with 2 parameters. So
> whoever provides such an Environment implementation has to adapt his
> implementation in a meaningful way anyway (empty implementation returning
> null, throwing NotSupportedException, whatever would not work). So it's the
> same effort for them whether to add a new method or changing existing one on
> the interface.

I don't see that, you can continue the existing behaviour for those
who don't change?

>  IMO the decision should be made purely from a design perspective. Should  a
> configuration parameter passed around as method parameter though it is
> static through the whole lifecycle of the Environment instance? In a perfect
> world I'd say no :)

That makes sense.  Guess the question in that case is; are the are any
use cases where people could use such a parameter as not static?

> Which leaves the question how to inject the parameter.
> One place is on instantiation (e.g. CocoonServlet.getEnvironment(..) in 2.1,
> RequestProcessor.getEnvironment(..) in 2.2) which leaves us with the web.xml
> init parameter (or analogical alternatives for other environments) as
> described.
>
>  Another option I found is to setup the environment (i.e. injecting the
> parameter) while setting up the pipeline. AbstractProcessingPipeline is the
> place where we have access to the current flush buffer size parameter and
> call getOutputStream(..) on the environment. It has a method
> setupPipeline(Environment). Why not injecting the parameter(s) here? Due to
> its lifecycle changing the property of the environment should not cause any
> problem since it's a one-time usage object, no threading problems or
> something like that.
>

Seems reasonable.

[snip/]

-- 
Peter Hunsberger

Mime
View raw message