[infinispan-dev] ISPN-863 - Thoughts / Questions

[Manik Surtani]

I'll let Vladimir comment more as he wrote most of this code originally, but it sounds OK in principle.  

Would you need to check the memory usage on every put and replace?  Wouldn't this be expensive?  Couldn't this happen periodically?

On 14 Jan 2011, at 03:22, david marion wrote:

> I have been looking at the code and think I have a starting point on the design. Remember, the goal here is to be able to create a cache that uses expiration but has no defined cache size limit. Reading through the code, if ‘-1’ is specified for the eviction maxEntries, then a ConcurrentHashMap is created and used as the data container and no eviction is performed. Otherwise a BoundedConcurrentHashMap is created and used as the data container and eviction is performed according to the specified strategy.
>  
> Eviction currently appears to happen in two different ways:
>  
> 1.       If an entry is expired, then it can be evicted.
> 2.       If the number of entries in a segment of the cache contains more entries than “allowed” by the configuration.
>  
> Here are the modifications that I think need to be made. I have not made any code mods yet, so I don’t know for sure if this will work. Definitely looking for feedback.
>  
> Modify configuration in some way so that the following can be specified:
> The percentage value of used JVM memory (i.e. 95) at which entries should be evicted to try and avoid an OOM error.
> The number of items that should be evicted when memory reaches this threshold
> Modify LRU and LIRS Eviction class so that the accessQueue member can be accessed by the new Eviction class so that two access queues don’t have to be maintained.
> Create a new Eviction class, a subclass of  LIRS, where the accessQueue is used from the Eviction strategy the user specifies and the for loop in the execute method is exited when the evicted set equals value from 1.b above.
> Modify DataContainerFactory.construct() to call DefaultDataContainer.boundedDataContainer() regardless of eviction policy. This will always create a BoundedConcurrentHashMap
> Create an instance of the new Eviction class in each segment.
> Modify BoundedConcurrentHashMap.Segment put and replace methods such that when new values are going to be put into the Segment, the memory usage is checked and the execute method is called on the new Eviction class.
>  
> Questions:
>  
> What are the implications of using a BoundedConcurrentHashMap instead of a ConcurrentHashMap when maxEntries is set to -1?
>  
> Thoughts
>  
> This will not guarantee that an OOM error does not occur. It will attempt to guard against an OOM caused by putting new values into the cache. This will probably be more effective when the cache is being used in client/server mode, and less effective when used in embedded mode as to other code running in the JVM.
>  
>  
> -- Dave Marion
> 
>  
> From: manik at jboss.org
> Date: Tue, 11 Jan 2011 11:46:40 +0000
> To: infinispan-dev at lists.jboss.org
> Subject: [infinispan-dev] Poor man's size-based eviction Re: ISPN-863
> 
> Hi Dave
> 
> Just saw that you signed the contributor agreement.
> 
> So yeah, what you may want to look into is the EvictionManager [1] which will periodically have its processEviction() [2] method called.  This doesn't actually do any evictions here (named so for legacy reasons) since the current data container is self-sizing/evicting.  However it is still periodically invoked to purge expired entries.  
> 
> You can piggyback on the same invocation to test upper and lower bounds of memory utilisation (if enabled), but the bit that I still think you need to figure out is deciding which entries to evict, and how many of them to evict.
> 
> Cheers
> Manik
> 
> [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/eviction/EvictionManagerImpl.java
> [2] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/eviction/EvictionManagerImpl.java#L84
> 
> On 10 Jan 2011, at 11:08, Manik Surtani wrote:
> 
> Excellent, Dave.
> 
> You should probably come up with a design first - or maybe a prototype on your fork of the project on GitHub - and post it here for comment.
> 
> Cheers
> Manik
> 
> On 8 Jan 2011, at 00:34, david marion wrote:
> 
> Manik,
>  
> I am on the list. I will start getting my dev environment setup according to instructions on site.
>  
> Dave Marion
>   _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
> 
> Lead, Infinispan
> http://www.infinispan.org
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
> 
> Lead, Infinispan
> http://www.infinispan.org
> 
> 
> 
> 
> _______________________________________________ infinispan-dev mailing list infinispan-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev_______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110114/073c85a4/attachment-0001.html