Ard Schrijvers wrote:
Ard Schrijvers wrote:
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
Right, this will achieve the same effect.
<snip/>
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?
Looks good.
Vadim
