You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Paul Russell <pa...@luminas.co.uk> on 2000/09/14 20:31:23 UTC
[C2] Caching, target JDK and forgetful developers..
Hi all,
There've been a number of people talking on the list in recent
weeks about C2s caching (or rather lack of caching). This evening,
I had one of those bursts of enthusiasm and thought I'd look at
implementing it. Before I do, though, I just wanted to give
people a heads up, check nobody else is already doing it, and
ask a couple of questions.
Firstly, I've forgotten which JDK we're targetting at now, am
I safe to use SoftReference etc? (i.e are we jdk1.2 happy?)
Secondly, what kind of architecture do we want to use for
caching in cocoon2? There is already a 'Store' interface in
org.apache.cocoon.components.store, which looks like it fills
the requirements of a cache. Was this interface origionally
conceived for this purpose? Are there any reasons not to use
it?
Thoughts, and comments?
Paul
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: [C2] Caching, target JDK and forgetful developers..
Posted by Stefano Mazzocchi <st...@apache.org>.
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 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?
org.apache.avalon.util.pool.Pool
and I think we should move the discussion on the Avalon mail list since
PhantomReferencedPool should be something general enough to belong there
as well.
> 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.)
Avalon provides the classes to do this already (based on work done by
Peter, Berin and myself)
> 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 ;)
Oh no problems... we need a RT-email once in a while :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: [C2] Caching, target JDK and forgetful developers..
Posted by Paul Russell <pa...@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 <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: [C2] Caching, target JDK and forgetful developers..
Posted by Giacomo Pati <Gi...@pwr.ch>.
Paul Russell wrote:
>
> Hi all,
>
> There've been a number of people talking on the list in recent
> weeks about C2s caching (or rather lack of caching). This evening,
> I had one of those bursts of enthusiasm and thought I'd look at
> implementing it. Before I do, though, I just wanted to give
> people a heads up, check nobody else is already doing it, and
> ask a couple of questions.
>
> Firstly, I've forgotten which JDK we're targetting at now, am
> I safe to use SoftReference etc? (i.e are we jdk1.2 happy?)
We are targetting 1.2. I don't know if we need SoftReferences (see
comments below)
> Secondly, what kind of architecture do we want to use for
> caching in cocoon2? There is already a 'Store' interface in
> org.apache.cocoon.components.store, which looks like it fills
> the requirements of a cache. Was this interface origionally
> conceived for this purpose? Are there any reasons not to use
> it?
>
> Thoughts, and comments?
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. 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).
So, what's your comment now, Paul?
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch
Re: [C2] Caching, target JDK and forgetful developers..
Posted by Stefano Mazzocchi <st...@apache.org>.
Paul Russell wrote:
>
> Hi all,
>
> There've been a number of people talking on the list in recent
> weeks about C2s caching (or rather lack of caching). This evening,
> I had one of those bursts of enthusiasm and thought I'd look at
> implementing it. Before I do, though, I just wanted to give
> people a heads up, check nobody else is already doing it, and
> ask a couple of questions.
>
> Firstly, I've forgotten which JDK we're targetting at now, am
> I safe to use SoftReference etc? (i.e are we jdk1.2 happy?)
Yes, even if consider that SoftReferences have a problem: when the GC
runs wipes out all the memory... so you might want to fragment the cache
into a number of different soft-referenced stores.
> Secondly, what kind of architecture do we want to use for
> caching in cocoon2? There is already a 'Store' interface in
> org.apache.cocoon.components.store, which looks like it fills
> the requirements of a cache. Was this interface origionally
> conceived for this purpose? Are there any reasons not to use
> it?
No, that's exactly the reason why it's there :)
Anyway, please go on.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------