[jboss-dev-forums] [Design of JBossCache] - Re: Eviction redesign

[manik.surtani@jboss.com]

Okay, so here is what I propose (and yes, it will break existing custom eviction policies and cfgs).

Just to sum things up first, there are 4 tasks involved in the eviction system:

1.  Identify and record node activity (performed by the EvictionInterceptor, recorded on the Region)
2.  Triggering processing of eviction queue (performed either by the EvictionTimerTask, or manually by calling Region.getEvictionPolicy().getEvictionAlgorithm().process())
3.  Identifying which nodes are to be evicted: EvictionAlgorithm.process()
4.  Evicting the node: EvictionPolicy.evict();

2 triggers 3 which triggers 4, so logically only 2 need be exposed to users via an API.

E.g., Region should just have 3 eviction-related methods on its public interface:

  | Region.processEvictionQueue();
  | Region.resetEvictionQueue();
  | Region.putNodeEvent(); // used by the EvictionInterceptor
  | 

EvictionPolicy and EvictionAlgorithm are never exposed to client code.

Configuration

There have been requests for greater flexibility here, and I think there are 4 aspects to configuring eviction, which should be independent of one another:

* Region - region that the cfg applies to
* EvictionAlgorithm - how are nodes selected for eviction
* EvictionAlgorithmConfiguration - cfg details for an EvictionAlgorithm, such as maxNodes, etc.
* EvictionPolicy - what happens when nodes are evicted
* ancillary aspects to the eviction region such as queue size

The above will allow people to configure a LFUAlgorithm with, for example, SimpleEvictPolicy that just does a cache.evict().  Or, an LFUAlgorithm could be coupled with a RemoveOnEvictPolicy, which as the name suggests, does a remove.

Basically I see the following exposed on each of the interfaces:


  | EvictionPolicy.evict(Fqn f); // this is what happens when a node is evicted.
  | 
  | EvictionAlgorithm.process(Queue eventQueue, EvictionPolicy policy); // processes a region.  Decides what to evict, sets up internal queues, and then calls policy.evict();
  | 

Region.processEvictionQueue() would:


  | algorithm.process(eventQueue, policy);
  | 

I also propose that we change the XML configuration to be more consisent with what w are doing with cache loaders, to look like:


  |   <eviction wakeupInterval="5000">
  |     <region name="/org/mydata" policyClass="o.j.c.e.SimpleEvictPolicy" algorithmClass="o.j.c.e.LFUAlgorithm" eventQueueSize="100000">
  |       <properties>
  |         maxNodes=10
  |         timeToLive=300
  |       </properties>
  |     </region>
  |   </eviction>
  | 

What do people think?  The benefit is a much cleaner and easier-to-understand set of interfaces and extension points.



View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169644#4169644

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