cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: Cocoon uses unstable EventCache by default
Date Sun, 10 Aug 2003 18:46:12 GMT
Upayavira wrote:
> I have been having a good look around the caching code, and have found that, by 
> default, with the EventCache block enabled, Cocoon uses the EventCache code. 
> 
> Given that the code is marked unstable, wouldn't it make sense for the default 
> configuration of Cocoon use CacheImpl instead of EventAwareCacheImpl?

While I'm fine with your proposal, I should note that the _code_ isn't 
really unstable -- the API was definitely but is less so now.  I have 
been thinking of removing the draconian warnings from the javadoc and 
simply leaving the gump descriptor marked "unstable" since this is new
conceptually and probably isn't used in any live deployments yet.

When enabled, the EventAwareCacheImpl merely looks at each 
SourceValidity in a pipeline on its way into the cache and does nothing 
else if you aren't using any EventValidities.  This results in a net 
cost of about 3-10 calls to instanceof, which in my tests was a total of 
0-10ms (less than the resolution of the JVM IIUC, so hard to know what 
exactly).  I judged that this wasn't doing any harm, and even thought 
about whether it should just go in core (saw no reason for it, but just 
to give perspective).

> It seems to me that this block is somewhat different from many others. Disabling 
> Linotype or not because it is unstable won't affect the basic running of your 
> Cocoon setup. However, the EventCache is directly overriding something central 
> to a Cocoon system, i.e. its cache, with code marked unstable. This doesn't seem 
> ideal to me.

True that this is different than others - I'm fine to mark it excluded 
by default if there's still a level of concern.

> Best immediate solution to my mind is to mark EventCache block as excluded by 
> default in blocks.properties. Other solutions are likely to be a lot more 
> complicated.
> 
> [Geoff - nothing against your code! I have ideas where I might want to use it 
> myself, just going on your own labelling of the code as unstable!]

No offense taken at all - in fact very glad to hear you're thinking of 
trying it out as me, Unico and Peter H. are probably the only three that 
have looked at it much.  I'd love to hear any ideas you have for 
improvement or just to have you start hacking at it directly.

Geoff


Mime
View raw message