[infinispan-dev] Infinispan 4.1 | Eviction policies for Memcached protocol

[Galder Zamarreño]

On Sep 23, 2010, at 4:41 PM, Vladimir Blagojevic wrote:

> Owen,
> 
> By default all entries are immortal, that is, their expiration and lifespan are -1. Being immortal they are subject to eviction policies. As soon as they are not immortal, as you noticed, they are not subject to eviction policies and container size indeed can grow above limit specified in maxEntries. I will make sure that this is very clear in documentation. I admit it is not now :(

Hmmmm, should they really be exclusive? Just because you want your entries to expire if not used in 1h, you shouldn't give up on controlling the size of the cache, shouldn't you?

> 
> Your problem can be alleviated if you remove expiration element from XML configuration file. Let us know in the forum if the problem was indeed solved.
> 
> Regards,
> Vladimir
> 
> 
> On 2010-09-23, at 3:23 AM, Owen Tran wrote:
> 
>> Hi,
>>  
>> I’m actively trying to replace memcached with Infinispan with the memcached server. Swapping it in with my existing whalin client was very simple, I just had to disable the binary protocol. The problem I’m facing is that evictions based on maxEntries aren’t working. Here’s the configuration I’m using (btw, I’ve tried playing with all the parameters by trying different strategies, using DEFAULT threadPolicy, change wakeUpInterval, and maxEntries by powers of 2.
>>  
>> <infinispan>
>>         <global>
>>                 <globalJmxStatistics enabled="true"/>
>>         </global>
>>         <default>
>>                 <jmxStatistics enabled="true"/>
>>                 <eviction wakeUpInterval="500" maxEntries="1024" strategy="LIRS" threadPolicy="PIGGYBACK"/>
>>                 <expiration maxIdle="3600000" lifespan="-1"/>
>>         </default>
>> </infinispan>
>>  
>>  
>> Infinispan will remove entries that are expired, but it doesn’t seem to evict any items when the cache exceeds the number of maxEntries. I’ve enabled trace and using JMX to peer into the number of entries, and I easily exceed the maxEntries by running a junit test loading it with 10,000 entries.
>>  
>> I noticed in the DefaultDataContainer it only handles immortalEntries with the bounded concurrency map. Is the memcached server somehow only setting items as mortal entries? If so, this means that the behavior for this memcached is really deficient, since you’re bound by memory and can’t LRU once maxEntries is reached. The only saving grace are the expiration settings. Is there a suggestion on how I can fix this so I can have the behavior of LRU with eviction?
>>  
>> Thanks,
>> Owen
>>  
>>  
>> Code from DefaultDataContainer…
>>  
>> protected DefaultDataContainer(int concurrencyLevel, int maxEntries, EvictionStrategy strategy, EvictionThreadPolicy policy) {
>>  
>>       // translate eviction policy and strategy
>>       switch (policy) {
>>          case PIGGYBACK:
>>          case DEFAULT:
>>             evictionListener = new DefaultEvictionListener();
>>             break;
>>          default:
>>             throw new IllegalArgumentException("No such eviction thread policy " + strategy);
>>       }
>>  
>>       Eviction eviction;
>>       switch (strategy) {
>>          case FIFO:
>>          case UNORDERED:
>>          case LRU:
>>             eviction = Eviction.LRU;
>>             break;
>>          case LIRS:
>>             eviction = Eviction.LIRS;
>>             break;
>>          default:
>>             throw new IllegalArgumentException("No such eviction strategy " + strategy);
>>       }
>>       immortalEntries = new BoundedConcurrentHashMap<Object, InternalCacheEntry>(maxEntries, concurrencyLevel, eviction, evictionListener);
>>       mortalEntries = new ConcurrentHashMap<Object, InternalCacheEntry>(64, 0.75f, concurrencyLevel);
>>       entryFactory = new InternalEntryFactory();
>>    }
>>  
>> _______________________________________________________  
>> Owen Tran || VP, Engineering || ezRez Software, Inc. 
>> 
>>  
>> _______________________________________________
>> 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
> 
> 
> 
> 
> _______________________________________________
> 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