Have you configured an eviction policy?
No,how would I do this for my example. Can I base the policy on the consumed memory of the cache?
There's no bundled policy for this (yet) but you can write one. Commonly, the policies available cause removal based on usage and capacity.
Er, I should say "eviction"
Has anybody done this (eviction policy based on consumed memory) yet (now 7 months after the initial conversation)?
It's targeted for 2.1.0 (JBCACHE-11). If you feel like contributing it sooner, be my guest. :-)
What would be really nice to be able to do is to be able to separate the questions of: "Do I need to evict?" and "What should I evict?" into different responsibilities.... So that you could have an LRU eviction policy that evicts when a certain memory threshold is reached, or a FIFO eviction policy that evicts when a certain memory threshold is reached, or a MRU eviction policy that evicts when a certain memory threshold is reached, etc - without having to code a completely separate eviction policy for each.
Because all of the existing eviction policies assume that maxNodes is how to decide when to evict, it's hard/impossible to put a memory threshold into an eviction policy without also having to code the details of LRU/FIFO/MRU/etc.
I'm not really expecting anything to be magically done about this :-) , but I'd like to see if you disagree with me or have any good ideas about an approach for this (that doesn't involve wholesale changes in the org.jboss.cache.eviction package) that's a bit more flexible than subclassing LRUAlgorithm to make a LRUMemoryAwareAlgorithm, subclassing MRUAlgorithm to make MRUMemoryAwareAlgorithm, etc (which wouldn't be hard, but would be less than ideal from a code maintenance standpoint).
Don't take this answer as meaning anything beyond what I literally say, (particularly re: any particular approach) as I'm posting quickly and am not going to be careful about wording. :)
Thinking about separating concerns and designing to make it easy to do that is a good thing IMHO.
E.g. eviction now involves
1) cache providing information about cache events that can be used to make decisions.
2) deciding if I need to evict
3) deciding what to evict
4) mechanics of evicting
5) a background thread spawned by the cache to handle 2-4.
To the extent the current eviction subsystem makes it difficult to use those features a la carte, it would be good in theory to make it easier. For the EJB3 SFSB caching case I could foresee only wanting JBC support for 1,2,3. There's already a slightly custom implementation of 4, implemented in a not very clean way. I'd also somewhat like to get rid of #5 and have the EJB container use its own thread.
nnnnn - uncanny, I was thinking precisely the same thing yesterday while finishing up JBCACHE- 758, which has to do with an eviction policy based on number of attribs in a node.
You are correct that the overall design of eviction could do with some rework, concerns do overlap and lead to a pretty inflexible system.
I'm kicking off a thread in the design forum. Don't expect the design of eviction to change any time soon though, it may not happen till 3.0, but still worthwhile talking/thinking about.