Closed RovoMe closed 9 years ago
Hi Roman, It is expected behavior, please read the comment here. Expired entries can not be reached but when you check the size you may see that map still has some entries to be swept but eventually that size should come to zero. You can also check that behavior by using eventual assertions like this
As we are currently experimenting with Hazelcast for its applicability as a caching solution for a leaky-bucket filter, which relies on the eviction of entries, we noticed some inconsitencies with the timing behavior when entries actually evict.
As there might be different eviction time-frames for different clients (not sure if we are really going in that direction) we make use of put(K, V, long, TimeUnit). To test the eviction behavior of entries using this method we came up with this simple unit test:
There is no further configuration defined for this test (
INFORMATION: Loading 'hazelcast-default.xml' from classpath.
) and the unit-test is the only Hazelcast instance (Members [1] { Member [192.168.1.113]:5701 this }
). All except the last assert work correctly. The last assert only succeeds if theThread.sleep(...)
is set to three seconds in my particluar case.Is this behavior expected? Is there any other way to define client-specific time-outs of entries which do evict almost immediately after the specified TTL?