Hi Ivan, I’m for this approach
> 2) leave it as is, but explain in javadocs that it only works for on-heap > layer, that does not in fact evict blocks from the underlying offheap > layer. because it should be feasible to enable on-heap caching for IGFS, right? Using the memory policies. So, I would reimplement the tests with the on-heap caching enabling and checking up that data is pushed out of the heap. — Denis > On May 24, 2017, at 9:57 AM, Ivan V. <iveselovs...@gridgain.com> wrote: > > Hi, colleagues, > > as Ignite caches moved to paged offheap memory , the > IgfsPerBlockLruEvictionPolicy does not seem to work as expected any more, > because > 1) interface org.apache.ignite.cache.eviction.EvictionPolicy now only > defines "eviction from on-heap", not a real eviction, because each on-heap > cache is now accompanied with underlying off-heap cache. It can become > "real eviction" only for "on-heap-only" mode caches, once they get > implemented. > 2) for off-heap eviction an entire page is evicted, not a specific k-v > pair, and LRU policy is not exactly LRU any more (see > org.apache.ignite.configuration.DataPageEvictionMode#RANDOM_LRU). So, it > appears to be impossible to re-implement this policy for the off-heap layer. > > Thus, now IgfsPerBlockLruEvictionPolicy is not quite valid, and some of > corresponding tests fail > (org.apache.ignite.internal.processors.igfs.IgfsCachePerBlockLruEvictionPolicySelfTest#testDataSizeEviction, > org.apache.ignite.internal.processors.igfs.IgfsCachePerBlockLruEvictionPolicySelfTest#testBlockCountEviction) > > So, the options I see are: > 1) deprecate/remove IgfsPerBlockLruEvictionPolicy ; > 2) leave it as is, but explain in javadocs that it only works for on-heap > layer, that does not in fact evict blocks from the underlying offheap > layer. > > Please share your opinions.
