cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [C2] Caching, target JDK and forgetful developers..
Date Fri, 15 Sep 2000 14:16:18 GMT

--- Paul Russell <> wrote:
> On Thu, Sep 14, 2000 at 10:41:22PM +0200, Giacomo Pati wrote:
> > The forthcoming Avalon release has many things introduced that we
> should
> > use for our cache/store/pools implementations. They have made
> marker
> > interfaces like ThreadSafe, Recyclable and Poolable and
> corresponding
> > classes to build pools out of such marked classes.
> This sounds very promising. I must admit, it's been a while since
> I looked at Avalon. I'm ferreting though the changes since the
> last time I looked (which ws before /src/java was in use, scarily
> enough.
> > The revised
> > ComponentManger interface (implemented into today) will
> help
> > us to get that working the right way. Today it will create a new
> > instance of every component it is ask for (and that's why the store
> > component isn't usable today because the ComponentManager has no
> way to
> > check if it should create an instance of a component or not). The
> > pooling stuff would fit best for the sitemap components because
> many of
> > them (yes, almost all) are not thread safe and have to be
> instantiated
> > for every request. Pulling them out of an object pool would reduce
> > garbage collection. If you would volunteer for that job I would
> > encourage you to grab them from the Avalon CVS and look for those
> > Interfaces and classes and how they could be incorporated into C2
> (and I
> > have some spare time to go back to the halfway finished sitemap
> > documentation :<). I think the Avalon guys will release it very
> soon so
> > I do not expect any changes to those classes I've mentioned so far
> > (maybe except the ComponentManager).
> One thing ocours to me at this stage, and that is how we get
> a component which has been attained using
> ComponentManager.getComponent().
> back *into* the pool, once someone has finished with it, since there
> is currently no facility to release a component in the
> ComponentManager
> interface. One solution I can think of involves using
> PhantomReferences
> to find components that are otherwise unreferenced and drag them
> back into the Pool. Does this sound plausible, or did you have other
> ideas?

First we have to distinguish between the ComponentManager (CM) for the
general components defined in cocoon.xconf (which all classes in C2 can
use when they implement Composer) and which is implemented into today and the SitemapComponentManager (SCM) which will be
used exclusively by the sitemap engine.

Lets look at CM first.

The Components marked as ThreadSave are simply put into a serialized
HashMap of the Cocoon class. They were instantiated and initialized
during system startup (means during the scan of the cocoon.xconf file).
Those marked as Poolable are put into a pool of its own with a
ObjectFactory that can handle the other interfaces like Configurable
and Composer. These pools can also be put into the HashMap mentioned
above because the pool represents the role of the requested Components.
The CM can check if the requested Component is a Pool or a ThreadSafe
object to return the requested Component (but this does solve our
problem how to return it, hmmm..., should we return a reference to the
pool instead and leave it to the Composer putting requested Components
back into the pool?)
 You might have seen that the Recyclable interface extends Poolable and
the Pool can also manage Recyclable objects. I like to have the
requesting classes beeing responsable to give them back when they don't
use it anymore but have no idea at the moment how to solve that (as
you've read above :)

> In terms of the sitemap components, the best way to proceed seems
> to be to create a set of pools in AbstractSitemap's load_component
> method, ...

I'm not shure if the AbstractSitemap (the base class of a generated
sitemap) should implement the SCM or if we make a separate class for
the SCM and use that instead of the load_component method. It's
essential to have such a SCM because we want to introduce sitemap
inheritance. That means subsitemap should not have to define all the
usual components again but instead can use those defined in its parent
sitemap. For this we need a hierarchy of SCMs and a SCM can ask a
parent SCM for sitemap components (maybe you have a better idea?).
Because the geenrated sitemaps are already arranged in that hierarchy
we could implement it in the base class but it may be cleaner to
separate the SCM from the AbstractSitemap. What do you think?
> ... one for each classURL. 

Yes and no. Yes, creating a pool for each type of component. But no, to
destinguish them by classURL only. Look at the
...serializing.SVGSerializer in the sitemap. In one case it acts as the
svg2png serializer and in an other case as the svg2jpeg serializer.
There may be the same class defined many times as different types with
different configurations.

> We could either return them to the
> pool at the end of each request, or again use PhantomReferences to
> get the GC to do it for us. I was a C++ programmer in a former
> life, so my temptation is to do it explicitly if we can (I think
> you'll agree the whole aim of this section of code is to make it
> as fast and efficient as possible, therefore we don't want to
> make the GC do work that we're quite capable of doing ourselves.)

I agree. It's no problem for the SCM because we control it through the
sietmap engine. It's a problem for the CM because we can't controll all
the Composers other people will write sometimes.

> I'm still trying to get my head around the innards of the new
> sitemap engine and work out when we can route two threads through
> the same component, and when we can't. I assume the only time we
> can do that is if the configurations for the two instances of the
> component are equal(). It would seem sensible therefore, to keep
> a map of all active ThreadSafe components by their configuration
> objects. The only problem I see with this is that Configuration
> objects, being tree structures are quite slow to check the quality
> of. What I haven't worked out yet is whether two configurations
> would be the same object - i.e. can we use == instead.

This is why we can't distinguish components by their classURL. And also
there will only be a very few components which can implement ThreadSafe
because the Interface doesn't lead to thread safe objects. For example
the XMLProducers (Generator, Transformer) need to save the XMLConsumer
delivered at the setConsumer method they have to load with SAX events
into instance variables which would be overwritten by concurrent
thread. The XMLConsumers (Serializers, Readers) need to save the
OutputStream they have to write to according to the SAX events they
receive. The rest are Selectors, Matchers and (maybe) Actions because
they are only called at one method and don't have to save state
information into instance variables. One could use the ThreadLocal
stuff to make his Component thread safe and thus can mark it with the
ThreadSafe interface.

> I'm actually away on business today, so I'm not going to get a
> chance to look at this properly until saturday, but if you want
> me to have a look and see what I can do, that's great. In the
> mean time, if you could comment on the sanity or otherwise of
> the above, that'd be good!

I think you got enough to think and look about it with my comments
above :P

> Paul (oh, and excuse the stream of conciousness thing - that's
> what happens when I read code and write e-mails at the same
> time ;)

Don't worry, the same happens to me many times :-))


PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1 856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1 856 2201
Hintereichenstrasse 7           
CH-8166 Niederweningen                    Web:

Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!

View raw message