new eviction region issues

[mircea.markus]

At the moment, when we create a new eviction region and there are nodes in the cache for the given region, these nodes won't ever be evicted as no eviction events will be placed in eviction queue. This does not seem as right behavior as the eviction polices will not do what are expected to - because they are not aware of the real number of nodes in the region, but the number of nodes managed after region's creation.
To solve this I see to solutions:
1. forbid creation of regions which are not empty(through an exception)
2. populate eviction queue with create events for existing nodes
Others?
I vote for 1 as with 2 comes a number of complications: not all nodes were actually created at the same time; what if the number of existing nodes is greater than the max number of nodes the policy allows? These are issues that can only be resolved through assumptions - hard to explain to users and not always right for them.

[sancheski]

Hi,

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.

[manik]

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?

[sancheski]

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?

[brian.stansberry]

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.

[manik]

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?