Hi Owen, Thanks for the email but this list is for discussing development of Infinispan itself. For any user queries, please direct your question to the community forums in http://community.jboss.org/en/infinispan?view=discussions. So, please open a discussion there and we'll look at it. Cheers, On Sep 23, 2010, at 9: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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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 :(

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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 2010-09-23, at 10:49 AM, Galder Zamarreño wrote: > > 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? Yeah, maybe you are right. It is more intuitive that way. I admit, we really convoluted this one :) Manik, everyone else?

Hi all, Thank you all for the quick responses. I was expecting to be able to use both as well, Sanne. I wrote a junit test setting expiration -1 and doesn't matter. Once you put them in a cache with a time, it make those entries mortal. Do you still want me to create a bug in Jira or is this working as design? I'd be happy to update the documentation as well, since I spent a lot of time combing through the docs.

For my problem with the memcached protocol, I'll treat entries defined with 1 year out as immortal and use the put with key/value instead of the put with key/value/expiration/timeunit. Thanks, Owen -----Original Message----- From: Sanne Grinovero [mailto:sanne.grinovero@gmail.com] Sent: Thursday, September 23, 2010 7:56 AM To: infinispan -Dev List Subject: Re: [infinispan-dev] Infinispan 4.1 | Eviction policies for Memcached protocol 2010/9/23 Vladimir Blagojevic <vblagoje(a)redhat.com&gt;: > > On 2010-09-23, at 10:49 AM, Galder Zamarreño wrote: > >> >> 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? > > Yeah, maybe you are right. It is more intuitive that way. I admit, we really convoluted this one :) > > Manik, everyone else? I was really expecting to be able to use both :) cheers, Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Yes, the current design is different than 4.0. Treating all cache elements (be it mortal or immortal) as eviction candidates is the only thing that makes sense. Assign the created JIRA to me. Fix needs to be on all branches, except 4.0. Regards, Vladimir _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev