cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: my doubts about the current CocoonStoreJanitor/StoreJanitorImpl
Date Tue, 18 Jul 2006 12:07:54 GMT
Ard Schrijvers wrote:
> Now, suppose, the JVM is low on memory. Now, I am used to have 3 stores in my apps, namely
defaultTransientStore, eventAwareTransientStore and the EHDefaultStore. I am not sure how
about projects of other people/companies,

(we don't use EHDefaultStore in production. Since you've seen the source code, 
you already know why)

> but I know I can only get some memory free from the EHDefaultStore. The other stores
either store very small responses, or, like the defaultTransientStore, it only caches a couple
of xslt's, which are needed for so many pages, that removing them makes no sense. The StoreJanitorImpl
just removes keys+responses from one single cache at a time, and moves to the next cache the
next time. 

I can suggest you two easy enhancements to improve the situation.

1. Stores should have configuration which specifies whether store should 
register itself with the StoreJanitor or not. Default transient store can be 
configured to *not* register with janitor, so that all your XSLTs stay in memory.

2. StoreJanitor can have another eviction algorithm, namely, it should have an 
option to remove configured % of entries from *all* registered stores. So that 
it empties some part of all stores on each eviction run. It would make system 
behavior more even and stable, in situations were there are multiple stores with 
varying object sizes.

> I have had an email conversation with Greg Luck about this, the main developer from ehcache.
Since you cannot remove cachekeys + responses according the eviction policy defined in the
ehcache, he came up with the idea to add keys with empty responses. 

 From my POV, this is a flaw in the ehcache: if there is an eviction policy, 
there should be a way to use it.

> So, in the StoreJanitor, I check now wether the store is instanceof EHDefaultStore,

That's a really bad idea, in and by itself. Never rely on concrete 
implementations, always work against contracts (interfaces).


View raw message