[infinispan-dev] Passivation + eviction with new bounded data containers

Vladimir Blagojevic vblagoje at redhat.com
Tue Aug 17 04:51:24 EDT 2010


Fix is in on 4.1 and HEAD regarding the source of the problem traced down to BoundedConcurrentHashMap. Still consulting with Manik about elegant solution to entire problem of inconsistency window (limbo problem described below) introduced by having entries evicted on a separate thread. 

Regards,
Vladimir


On 2010-08-12, at 10:22 AM, Manik Surtani wrote:

> Guys,
> 
> A problem with eviction, passivation and the new data container has been reported in ISPN-582.  A quick summary, eviction now takes place within the data container as containers are naturally bounded.  This means once a size threshold is reached entries are automatically removed.  More accurately, they are just stored in a separate collection and the eviction thread picks them off this collection and calls evict() on each one.  Now we have some issues here:
> 
> 1) This means notifications are often dispatched later than when the actual eviction takes place.  No biggie though, eviction is best-effort.
> 2)  Passivation too is delayed.  This is huge.  This means there is a window where a thread may ask for an entry but the entry is in limbo - not in the data container, not yet passivated to a cache store.
> 
> I am currently testing a fix for this, where the data container handles notification + passivation (if enabled) directly, when an entry is evicted from the primary data collection.  So far this seems to work, however this all happens on the caller's thread now.  So in a sense, I wonder if the EvictionThreadPolicy is relevant.
> 
> However, my fix is only a temporary one - since it still doesn't work when using LIRS, as LIRS maintains 2 separate stacks and only the LIR stack is queried on a get and not the HIR stack.  So for now we should consider LIRS + Passivation as an invalid configuration.
> 
> 	https://jira.jboss.org/browse/ISPN-598
> 
> Anyway the key thing is, it all works fine now, so lets open this discussion again when Vladimir is back from vacation.
> 
> Cheers
> Manik
> 
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Vladimir Blagojevic
JBoss Clustering Team
JBoss, by Red Hat







More information about the infinispan-dev mailing list