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?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4142412#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...