[jboss-dev-forums] [Design of JBossCache] - Re: Eviction redesign
manik.surtani@jboss.com
do-not-reply at jboss.com
Fri Aug 8 12:28:07 EDT 2008
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
More information about the jboss-dev-forums
mailing list