-
1. Re: Overflow berfore OutOfMemory
manik Dec 4, 2006 9:29 AM (in response to mzehrer)Have you configured an eviction policy?
-
2. Re: Overflow berfore OutOfMemory
mzehrer Dec 4, 2006 9:49 AM (in response to mzehrer)No,how would I do this for my example. Can I base the policy on the consumed memory of the cache?
-
3. Re: Overflow berfore OutOfMemory
genman Dec 4, 2006 4:50 PM (in response to mzehrer)There's no bundled policy for this (yet) but you can write one. Commonly, the policies available cause removal based on usage and capacity.
-
4. Re: Overflow berfore OutOfMemory
genman Dec 4, 2006 4:50 PM (in response to mzehrer)Er, I should say "eviction"
-
5. Re: Overflow berfore OutOfMemory
nnnnn Jul 6, 2007 4:31 PM (in response to mzehrer)
Has anybody done this (eviction policy based on consumed memory) yet (now 7 months after the initial conversation)? -
6. Re: Overflow berfore OutOfMemory
manik Jul 10, 2007 12:21 PM (in response to mzehrer)It's targeted for 2.1.0 (JBCACHE-11). If you feel like contributing it sooner, be my guest. :-)
-
7. Re: Overflow berfore OutOfMemory
nnnnn Jul 16, 2007 5:59 PM (in response to mzehrer)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). -
8. Re: Overflow berfore OutOfMemory
brian.stansberry Jul 17, 2007 7:45 PM (in response to mzehrer)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. -
9. Re: Overflow berfore OutOfMemory
manik Jul 18, 2007 5:19 AM (in response to mzehrer)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.