Question about LRU in a replicated cache

Question

Hi Tangosol,
I have a question about how the LRU eviction policy works in a replicated cache that uses a local cache for its backing map. My cache config looks like this:
<replicated-scheme>
<scheme-name>local-repl-scheme</scheme-name>
<backing-map-scheme>
<local-scheme>
<scheme-ref>base-local-scheme</scheme-ref>
</local-scheme>
</backing-map-scheme>
</replicated-scheme>
<local-scheme>
<scheme-name>base-local-scheme</scheme-name>
<eviction-policy>LRU</eviction-policy>
<high-units>50</high-units>
<low-units>20</low-units>
<expiry-delay/>
<flush-delay/>
</local-scheme>
My test code does the following:
1. Inserts 50 entries into the cache
2. Checks to see that the cache size is 50
3. Inserts 1 additional entry (as I understand it, this should cause the eviction logic to kick-in)
4. Checks the cache size again, expecting it to now be 20
With HYBRID and LFU eviction policies, the above logic works exactly as expected. When I switch to LRU however, the code at step 2 always returns a value significantly less than 50. All 50 inserts appear to complete successfully, so I can only assume that some of the entries have already been evicted by the time I get to step 2.
Any thoughts?
Thanks.
Pete L.
Addendum:
As usual, in attempting to boil this issue down to its essential elements, I left out some details that turned out to be important. The logic that causes the condition to occur looks more like:
1. Loop 2 times:
2. Create named cache instance "TestReplCache"
3. Insert 50 cache entries
4. Verify that cache size == 50
5. Insert 1 additional entry
6. Verify that cache size == 20
7. call cache.release()
8. End Loop
With this logic, the problem occurs on the second pass of the loop. Step 4 reports a cache size of < 50. This happens with LRU, LFU, and HYBRID-- so my initial characterization of this problem is incorrect. The salient details appear to be that I am using the same cache name each pass of the loop and that I am calling release() at the end of the loop. (If I call destroy() instead, all works as expected.)
So... my revised question(s) would be: is this behavior expected? Is calling destroy() my only recourse?
Message was edited by: planeski

Answer 1

Robert,
Attached are my sample code and cache config files. The code is a bit contrived-- it's extracted from a JUnit test case. Typically, we wouldn't re-use the same cache name in this way. What caught my eye however, was the fact that this same test case does not exhibit this behavior when running against a local cache directly (as opposed to a repl cache backed by a local cache.)
Why call release? Well, again, when running this same test case against a local cache, you have to call release or it won't work. I figured the same applied to a repl cache backed by a local cache.
Now that I understand this is more a byproduct of how my unit tests are written and not an issue with LRU eviction (as I originally thought), it's not a big deal-- more of a curiosity than a problem.
Pete L.<br><br> <b> Attachment: </b><br>coherence-cache-config.xml <br> (*To use this attachment you will need to rename 545.bin to coherence-cache-config.xml after the download is complete.)<br><br> <b> Attachment: </b><br>LruTest.java <br> (*To use this attachment you will need to rename 546.bin to LruTest.java after the download is complete.)