9 Replies Latest reply on Jul 18, 2007 5:19 AM by Manik Surtani

    Overflow berfore OutOfMemory

    Michael Zehrer Newbie

      How can I configure the cache in a way, that it will not exceed the maxheap of my jvm? I want to create a real big cache used as a data store. I used passivation=true, but then nothing was written to the persistent storage.

      Best, Michael

        • 1. Re: Overflow berfore OutOfMemory
          Manik Surtani Master

          Have you configured an eviction policy?

          • 2. Re: Overflow berfore OutOfMemory
            Michael Zehrer Newbie

            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
              Elias Ross Master

              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
                Elias Ross Master

                Er, I should say "eviction"

                • 5. Re: Overflow berfore OutOfMemory
                  Nolan Johnson Newbie


                  Has anybody done this (eviction policy based on consumed memory) yet (now 7 months after the initial conversation)?

                  • 6. Re: Overflow berfore OutOfMemory
                    Manik Surtani Master

                    It's targeted for 2.1.0 (JBCACHE-11). If you feel like contributing it sooner, be my guest. :-)

                    • 7. Re: Overflow berfore OutOfMemory
                      Nolan Johnson Newbie

                      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 Master

                        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 Surtani Master

                          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.