Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Date: Fri, 15 Sep 2000 10:02:22 +0100
From: Paul Russell <paul@luminas.co.uk>
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] Caching, target JDK and forgetful developers..
Message-ID: <20000915100221.B21077@brit.luminas.co.uk>
References: <20000914193122.K13599@brit.luminas.co.uk>
 <39C137F2.5E21D5DC@pwr.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <39C137F2.5E21D5DC@pwr.ch>;
 from Giacomo.Pati@pwr.ch on Thu, Sep 14, 2000 at 10:41:22PM +0200
Organisation: Luminas Ltd.
Sender: Paul Russell <paul@luminas.co.uk>

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 Cocoon.java 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?

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, one for each classURL. 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'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.

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!


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 ;)

-- 
Paul Russell                               <paul@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.