[infinispan-dev] Eviction thread and purging expired entries

Galder Zamarreño galder at redhat.com
Thu Jul 22 04:03:17 EDT 2010


On Jul 22, 2010, at 3:49 AM, Mircea Markus wrote:

> 
> On 21 Jul 2010, at 19:29, Galder Zamarreño wrote:
> 
>> 
>> On Jul 21, 2010, at 3:24 PM, Mircea Markus wrote:
>> 
>>> Hi,
>>> 
>>> Eviction thread does two things right now:
>>> - evict stuff from DataContainer
>>> - purge entries from a CacheStore
>>> 
>>> CacheStore.purge might slow down eviction as it is generally an expensive operation. It might not even be needed, if the users don't use expiration. 
>> 
>> It's not considered here, but I think it'd be hard to figure out that expiration is not in use at runtime. You'd have to track calls with expiration and make sure there's at least one expiration that has not expired. Probably not practical.
> well spotted! Not hard to implement, and definitely simple for the users, as doesn't need an additional config.
>> 
>>> What about: 
>>> a) making EvictionThread.purgeCacheStore configurable. 
>>> or/and
>>> b) use another thread for purging the store. 
>>> 
>>> This doesn't came out of the blue, there's a user that has eviction+cache store configured with eviction thread wakeup set to 1 sec - he still gets OOM.
>>> 
>>> Wdyt?
>> 
>> I think both are valid actually but let me be more precise.
>> 
>> More than making EvictionThread.purgeCacheStore configurable, I'd make expiration as a whole configurable. So, if user does not use expiration, having expiration=false would:
>> - Disallow calls to overloaded cache methods taking expiration
>> - Do not check for expiration when entries are retrieved from memory/cachestore
>> - Don't do EvictionThread.purgeCacheStore 
> This would also make sure that the user won't add expiry stuff by mistake.
> I like both solutions :)

I think I forgot to add a comment on using a separate thread for purging the store. I think this is definitely a valid option for cases where user does need expiration but for some reason purging the cache store is expensive.

So, just reiterating what I said above, two options valid imo.

> 
>> 
>> 
>>> 
>>> Cheers,
>>> Mircea
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> 
>> 
>> _______________________________________________
>> 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

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list