Have you configured an eviction policy?

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.