I agree with your suggestions.

But from what I gather, by being able to disable the eviction thread, you effectively have all of the a la carte combos you want.

What really is need here, then, is just some tidying up and formalisation of the public API and SPI. TBH, I think Regions are desperately in need of some formalisation as well - it is a bit of a free-for-all at the moment and that's a bit sucky.

Let me have a think about it and put up some ideas. I think eviction and regions will need to be done hand-in-hand, and that will then suck in marshalling regions as well.

Also see http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4168408#4168408

Also look at JBCACHE-1141

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.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();

algorithm.process(eventQueue, policy);

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

Re: XML configuration, I also propose dropping defaultPolicyClass and defaultEventQueueSize from the eviction element since there is a default element within the eviction element to denote settings for the default region, e.g.:

 <eviction wakeUpInterval="5">
 <default policyClass="o.j.c.e.SimpleEvictPolicy" algorithmClass="o.j.c.e.LFUAlgorithm" eventQueueSize="100000">
 <properties>
 maxNodes=10
 timeToLive=300
 </properties>
 </default>
 </eviction>

<region name="/" ...>

In terms of breaking compatibility, here is the impact:

1. XML cfg

No impact here since XML cfg is changing anyway. Mircea's translation script can be modeified to take care of this.

2. Programmatic cfg

* Minor impact, EvictionConfig.set/getDefaultXXX will go away.
* XmlConfigurationParser would have to create a normal EvictionRegionConfig for the default element and add it to the EvictionConfig using setDefaultEvictionRegionConfig().
* All other EvictionRegionConfigs will inherit values from EvictionConfig.getDefaultEvictionRegionConfig() for unset properties. This could be done by EvictionConfig when addEvictionRegionConfig() is called.
* XXXPolicyConfig will have to be replaced with XXXAlgorithmConfig.
* EvictionPolicyConfig interface replaced with EvictionAlgorithmConfig
* EvictionRegionConfig references to EvictionPolicyConfig will be changed to EvictionAlgorithmConfig
* EvictionRegionConfig will also take in a EvictionPolicy class name.

3. Using Region

* getEvictionPolicy(), getEvictionPolicyConfig(), getEvictionRegionConfig(), and all other eviction related methods will disappear, save for the 3 methods detailed above.

4. Implementing custom eviction algorithms.

* If extending an existing EvictionAlgorithm or the BaseEvictionAlgorithm, this should be simple and not require any changes.
* Any new algorithm implemented will have to provide an EvictionAlgorithmConfig instead of an EvictionPolicyConfig

I suppose the impact of #2 above could be minimised by:

* Keeping EvictionPolicyConfig but marking it as deprecated
* EvictionRegionConfig could issue a warning if an EvictionPolicyConfig is used, and copy all values across from here to an EvictionAlgorithmConfig
* Use a default EvictionPolicyClassName if none is specified (default: SimpleEvictionPolicy that just does Cache.evict()?)

"bstansberry@jboss.com" wrote:
The defaultPolicyClass and defaultEventQueueSize do more than define the values for the "/" region. They also let you skip specifying those values for other regions you define.

IMO it's OK to drop that feature if doing so makes things meaningfully cleaner. Just wanted to point out that the feature exists.

"manik.surtani@jboss.com" wrote:

...
* All other EvictionRegionConfigs will inherit values from EvictionConfig.getDefaultEvictionRegionConfig() for unset properties. This could be done by EvictionConfig when addEvictionRegionConfig() is called.
...

"bstansberry@jboss.com" wrote:
Perhaps a different name for "EvictionPolicy", maybe "EvictionActionPolicy" or something. Using the same term for a different thing will be confusing.

"bstansberry@jboss.com" wrote:
Hmm -- if I do this

cache.put(Fqn.fromString("/a/really/deeply/nested/node", "key", "value")

and all the higher level nodes already exist, are any eviction events generated for "/a", "/a/really", "/a/really/deeply", "/a/really/deeply/nested"?

Region.putNodeEvent(Fqn fqn, NodeEventType type, int elementDifference)