[jboss-dev-forums] [Design of JBossCache] - Design of JBCACHE-1316

[galder.zamarreno@jboss.com]

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#4142412

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4142412