cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [C2] [Patch] And another one (Component optimisation)
Date Wed, 29 Nov 2000 10:37:07 GMT

--- Paul Russell <> wrote:
> On Tue, Nov 28, 2000 at 03:48:44AM -0800, Giacomo Pati wrote:
> > I propose Paul Russel becoming a committer to the Apache Cocoon
> project
> > because I'm too lazy to check in all his patches (past ones and
> futer
> > ones :).
> Heh. Thanks. While we wait to see who's happy with that, here's
> another to keep you busy ;)
> I'm leaving most of the XSP engine be for the time being, until
> I'm comfortable that I'm not going to introduce race conditions
> left right and centre. I'm also a touch worried about the
> generator API, because at present, we *have* to mark them all as
> poolable at best, because of the two phase setup/generate. The
> rules of functional programming indicate that this should just
> be a one stage thing.  If they were one stage, we might be able
> to move over to making most of them ThreadSafe in due course.

This will go much deeper that it seems you are aware of :(). You
suggestion will impose to rethink the very basic interfaces we have
defined. The SitemapModelComponent defines the setup method to get
access to the objectModel, parameters, etc. during request evaluation
time. It's used in the Generator, Reader and Transformer interfaces so
far. Changing the Generators generate method in the way you propose
(and thus this should affect the Reader interface as well) makes the
SitemapModelComponent interface somehow obsolete because the only
remaining component using that interface is the Transformer. 

Doing so the Generator and Reader will have a common method (generate)
which we can manifest in a common interface. But be aware that this
will *not* make the Generators ThreadSafe. The main crux is the
XMLProducer interface with the setConsumer method which needs a class
level variable to store that XMLConsumer the Generator spits its SAX
events to during execution of its generate method.

Changing the XMLProducer interface will affect again the Transformer
and the Serializer. And this is why I've initialy said we have to
rethink the basic block of Cocoon 2.

Because of that I propose to think about what the real benefit will be
to make generators thread safe instead of "only" Poolable (beside
memory consumption because of the pools).

> When I was playing 'spot the race condition', I suffered from
> a problem in org.apache.cocoon.sitemap.ResourcePipeline's
> process method, where the Generator was failing to get its
> content handler set. I can't see any sensible reason why it
> should happen, and setting the method to synchronized solved
> the problem, but can I now replicate it to give you a stacktrace?
> Gah. I hate race conditions.

This is very strange. The ResourcePipeline object is not used in a
multi threaded way. The sitemap engine instantiates a ResourcePipeline
for every request it handles (at least this was my intention when I've
designed it)

> I'm also getting the following stack trace depressingly regularly:
> javax.xml.transform.TransformerException: Broken pipe
>         at
>         at
>         at org.apache.cocoon.Notifier.notify(
>         at
>         at


Well, maybe there is an error in a Transformer which kills the pipeline
in action and tries to setup an error pipeline to report the error
(ErrorNotifier). I have no idea at the moment, sorry.



Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.

View raw message