In my opinion, I vote for 2.
what if the number of existing nodes is greater than the max number of nodes the policy allows?
The nodes exisiting in a region should be populated to the eviction queue keeping the order they were created. Thus, if the number of existing nodes is greater than the max number of nodes the policy allows, they will be evicted as they should.
This would be a high cost requirement, but it deals to a consitent solution.
In what cases are eviction regions created after nodes are created in the cache? The only potential situations I can think of are preloading from a cache loader or a state transfer, both of which happen during startup, before the region is created. Perhaps we should look into reordering the startup sequence so that any preloading or state transfer happens after eviction regions are set up, and that preloading and state transfer create the necessary events in the eviction queue?
See this post http://www.jboss.com/index.html?module=bb&op=viewtopic&t=135031
In this case, it has not to do with the startup process. What would happen if you create an eviction policy region in an fqn that is not empty?
For the EJB3 SFSB cache I do something similar to what Sancheski describes. I realize now it works OK because that cache has useRegionBasedMarshalling=true, so even though the cache is started the region is empty when I programatically add the eviction region config. That's kind of a fortunate fluke though; being able to programatically add the region without requiring region-based marshalling would be nice. Without region-based marshalling, there could be pre-existing nodes.
I wouldn't worry about the # of preexisting nodes exceeding maxNodes issue. The first time the eviction thread runs, it will take care of it; it's the job of eviction processing to worry about that.
Re: every pre-existing node having the same timestamp in the eviction queue, oh well. Don't see any way around that without storing a creation timestamp in each node, which IMO is big time overkill. The main thing is making sure the policy knows about all nodes.
I agree, I think it is fair that the eviction algorithm sees all nodes as having the same creation timestamp for preexisting nodes.
But going back to the whole thing of programmatic creation of eviction regions - I'm pretty sure this is an "unintentional" feature. :-) I can see how it can be useful and ought to be a real feature, but the way evictions work (as you can see from this thread) it is clearly not designed to be configured on the fly.
Let's think about what we need to add to eviction configuration to make it dynamic - so far we just have the issue of pre-existing nodes. Anything else?