cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: my doubts about the current CocoonStoreJanitor/StoreJanitorImpl
Date Tue, 18 Jul 2006 12:52:50 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.

StatusGenerator can't give the status of stores not registered to the StoreJanitor. I would
rather still register them to the StoreJanitor, but configure them not to be "cleared" by
the StoreJanitor

> 
> 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.

This in combination with (1) would then change into removing entries from *all stores configured
to be clearable by the StoreJanitor*. Rest seems fine to me

> 
> 
> > 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.

Of course I agree on this one. I'll ask on the ehcache mailinglist if there is a way to solve
this. 
> 
> 
> > 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).

Ok. I try and see if there is another way to get this in. I still have to do the following
changes then

1) StoreJanitor to only free cache/memory from stores configured to
2) Change the EHDefaultStore the "public int size()"  to return the memoryStoreSize()
3) Change the free() in EHDefaultStore according to the correct eviction policy. This might
need changes in the ehcache. 

I think this meets your requirements as well, right?

Regards Ard

> 
> 
> Vadim
> 
> 

Mime
View raw message