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