Design of JBCACHE-1316

[galder.zamarreno]

Re: http://jira.jboss.com/jira/browse/JBCACHE-1316

I've got this one ready to go into trunk. If everyone's happy with the approach below, I'll port it to 2.1.x and the 1.4.x branch.

I've created a new test class called org.jboss.cache.eviction.BaseEvictionAlgorithmTest rather than extending one of existing LRU/LFUAlgorithm test classes because the test focuses on what BaseEvictionAlgorithm does rather than the specifics of each algorithm. Within it, we test whether the eviction algorithm process blocks forever if the recycle queue gets filled up.

The fix itself consists of changing the following line in BaseEvictionAlgorithm.evict(NodeEntry ne):

recycleQueue.put(ne.getFqn());

To look like this and avoid potentially blocking forever:

boolean result = recycleQueue.offer(ne.getFqn(), 5, TimeUnit.SECONDS);
if (!result)
{
 log.warn("Unable to add Fqn[" + ne.getFqn() + "] to recycle " +
 "queue because it's full. This is often sign that " +
 "evictions are not occurring and nodes that should be " +
 "evicted are piling up waiting to be evicted.");
}

The recycle queue size is not configurable and so, don't think the recycle queue offer timeout should be either. 5 seconds looks to me a reasonable timeout to be able to put an Fqn in the recycle queue.

Thoughts?

[manik]

In 1.4.X, shouldn't the bounded buffer also be initialised with something a bit bigger than the default 1024?

[galder.zamarreno]

In 1.4.X, shouldn't the bounded buffer also be initialised with something a bit bigger than the default 1024?

+1.

One step at the time. I wanted to get solution on trunk agreed and then move on to other branches.

The default value is trunk is 500000, so maybe we should use this one as well for 1.4.x? I can't see any reason why it should be different. 1024 is certainly too small.

[manik]

Agreed.

No issues with putting this in branch 1.4.X, 2.1.X and trunk.

[galder.zamarreno]

In 1.4.X, shouldn't the bounded buffer also be initialised with something a bit bigger than the default 1024?

Actually, looking at this again. You had already changed the capacity of the recycle queue to 20000 rather than the default 1024 somewhere in between 1.4.0.SP1 and 1.4.1.SP3, so we're fine there.