Eviction vs Expiration

Solution Verified - Updated -

Environment

  • Red Hat Data Grid (RHDG)
    • 8.x
    • 7.x
    • 6.x

Issue

  • What is the difference between Eviction and Expiration?
  • Entries are missed if eviction is configured without a cache-store

Resolution

Eviction is intended to control the total size of the cache. This is to prevent each cluster member from experiencing an OutOfMemory issue, it will not remove the entry from the cluster if configured correctly.
Expiration is intended for a per-entry approach. It will remove an entry from the cluster after a defined lifetime or without accessed after a period, the entry will be removed on all nodes and persistent cache-stores of the cluster.
In other words, eviction is for DG 8 to keep from using too much memory, so only size-based configuration options make sense for it.

Expiration

With expiration each entry can be marked with a lifetime or max-idle time. After reaching that threshold the entry will be removed from the whole cluster and its cache-stores.
Note that the max-idle approach is not recommended for clustered caches until RHDG7.2 because of some limitations, see this article for more details.
Setting expiration can be done with max-idle and lifespan.

Property Meaning
lifespan Specifies the maximum amount of time, in milliseconds, that a cache entry stay on the cache lifespan.
max-idle Specifies the maximum amount of time, in milliseconds, that cache entries can remain idle. If no operations are performed on entries within the maximum idle time, the entries expire across the cluster. A value of 0 or -1 disables expiration.

Note: Lifespan > max-idle (or lifespan not >= max-idle) should only be used on clustered caches if absolutely necessary since there's a big performance penalty on reads.

Eviction

Eviction is acting local on every node and will remove unused entries from the memory to prevent OutOfMemory isses, with a cache-store the entry is still available and the next access will bring it back into memory.
It is not recommended to use eviction in a cluster without a cache-store as the results are not deterministic

Here an example in detail:

  • assume 5keys 1,2,3,4,5 - 3 nodes
  • at the beginning all nodes have all keys as the cache is REPL
  • add 6
  • one node will evict 1, other node might evict 2, the next might evict 3. This is because the algorithm is not deterministic and depend on different conditions.
  • as result you have different keys on each node and it depends which node you are on what the result of a get is
    node1 -> 2,3,4,5,6
    node2 -> 1,3,4,5,6
    node3 -> 1,2,4,5,6

As shown the result is not deterministic, it depends on the DG mode (client-server or embedded) whether the entries can be seen, in any case, the cluster gets inconsistent after rebalance operations.
Because of this, it is strongly recommended to use eviction only if there is a persistence configured!

Eviction strategies:

Strategy Purpose
when-full(REMOVE) Remove old entries to make space for new ones given max-count or max-size
when-full(MANUAL) Manual eviction via evict() method
when-full(EXCEPTION) it throws a ContainerFullException exception and does not allow the new entry

Here is the relevant section of the docs :
RHDG 7.2 Administration Guide - Eviction and Expiration

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments