[infinispan-issues] [JBoss JIRA] Updated: (ISPN-1347) LIRS eviction not evicting correctly

LIRS eviction not evicting correctly ------------------------------------ Key: ISPN-1347 URL: https://issues.jboss.org/browse/ISPN-1347 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 5.0.0.FINAL Reporter: Jozef Vilkolak Assignee: Vladimir Blagojevic Priority: Critical Fix For: 5.1.0.ALPHA2 , 5.1.0.FINAL It seems LIRS eviction at this moment only evicts the first entry in the HIR queue and nothing else. I have written a test based on [this presentation|https://docs.google.com/viewer?a=v&q=cache:jcEF5qSkCo4J:...] located in the eviction-strategy module of [edg-functional-tests|https://svn.devel.redhat.com/repos/jboss-qa/edg/edg-...] that is at the moment failing. Upon closer examination I have found a couple of things I think may be the cause: * in infinispan.util.concurrent.BoundedConcurrentHashMap ** in execute() of the LIRS eviction if you have more items in the accessQueue and while processing you choose an item to be evicted it is added to the evicted Set. But if it is still in the accessQueue(and the operation was put) it gets proccesed but in the end still ends up evicted because it was not removed from the evicted set. ** in onEntryMiss of the LIRS eviction the very first if shouldn't first increment currentLIRSize because otherwise LIRSize is never full and therefore the LIRS algorithm never truly happens because execute() is never called that's why it only evicts from the HIR queue. It also causes the cache to be able to hold only maxEntries-1 entries. Also if (queue.size() < hirSizeLimit) condition is true the item should also be added to the stack in order to track its recency. And lastly I don't think onEntryMiss should be evicting elements because that way we can't track their recency. They will get eventually evicted by pruning. ** the function onEntryRemove should not in my opinion remove entries from the stack because otherwise there is no way to track recency of HIR-nonresident blocks. They will eventually get removed from the stack by pruning. It also seems this function gets called when clearing the cache instead of clear. * in Segment class ** the remove operation makes entries behave as if they were just added as is already documented there with a TODO ** the get operation calls onEntryHit which can cause problems if get is used while servicing a put operation because it gets called twice If some of these things were design choices let me know so I will modify the test.