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

[Sanne Grinovero]

2010/8/12 Manik Surtani <manik at jboss.org>:
> 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.
>

thanks for the nice explanation, very valuable.
Did you consider that the "limbo" area could be promoted to be a valid
place to look for entities when they are not found in the main
container, and before trying a load from a store?
Basically you would have your container split in two areas, something
like JVM heap areas; I guess that would be quite a change.

Sanne