cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: AW: Desparately seeking help with pipeline implementation
Date Sun, 30 Apr 2006 22:01:16 GMT
Stefan Pietschmann wrote:
> | -----Urspr√ľngliche Nachricht-----
> | Von: Sylvain Wallez []
> | Gesendet: Sonntag, 30. April 2006 14:00
> | An:
> | Betreff: Re: Desparately seeking help with pipeline implementation
> | 
> | Stefan Pietschmann wrote:
> | >
> | > Hi guys,
> | >
> | > for my thesis I have implemented a custom pipeline, which modifies the
> | > list of transformers to be run during pipeline setup. This is done
> | > with every request in setupPipeline(), so I need to reset to the
> | > original every time, before I modify again.
> | >
> | 
> | Why do you need that? Can't it be done by overloading one of
> | setGenerator/addTransformer/setSerializer?
> I adapt the pipeline with every request according to some external data.
> Isn't addTransformer() called only once when the pipeline is built? If it
> is, I couldn't use it, because this would mean I adapt the pipeline once,
> and all subsequent requests use the adapted one. 
> However, if this.transformers (and the other ArrayLists with the sources and
> parameters) is built anew for every request, then this might be an easy way
> out.

The contents of a pipeline is not reused across requests! All components
are releases and cleared in recycle(), which occurs once the pipeline
has been executed.

The setGenerator/addTransformer/setSerializer are called by the sitemap
engine when executing <map:generate>, <map:transform> and
<map:serialize> respectively.

This is probably a good place if you want to automatically add some
components to the pipeline, particularly considering that pipeline cache
key and validity computation happens after these methods. Now if you
remove some of the components that were already in the pipeline, don't
forget to release them or you may encounter some memory leaks in object
pools (see the code in AbstractProcessingPipeline)

> | Giving more details about the errors you obtain would be useful, but I
> | guess this is more related to component pools than to multithreading.
> I can attach some stacktraces if that helps...

Yes, it always helps.

> I only see that I only get problems when using multiple threads. The problem
> might be related to anything else - I don't seem to understand how a
> pipeline is used by multiple threads. I thought - since it's recycleable -
> that each thread gets its own pipeline object.

Yes, pipelines are not shared among threads. But if you do some "nasty"
things with the pipeline components, it may happen that the pipeline is
not be correctly recycled and therefore components used by multiple


Sylvain Wallez -

View raw message