Chapter 2. Set Up Eviction

2.1. About Eviction

Eviction is the process of removing entries from memory to prevent running out of memory. Entries that are evicted from memory remain in configured cache stores and the rest of the cluster to prevent permanent data loss. If no cache store is configured, and eviction is enabled, data loss is possible.

Red Hat JBoss Data Grid executes eviction tasks by utilizing user threads which are already interacting with the data container. JBoss Data Grid uses a separate thread to prune expired cache entries from the cache.

Eviction occurs individually on a per node basis, rather than occurring as a cluster-wide operation. Each node uses an eviction thread to analyze the contents of its in-memory container to determine which entries require eviction. The free memory in the Java Virtual Machine (JVM) is not a consideration during the eviction analysis, even as a threshold to initialize entry eviction.

In JBoss Data Grid, eviction provides a mechanism to efficiently remove entries from the in-memory representation of a cache, and removed entries will be pushed to a cache store, if configured. This ensures that the memory can always accommodate new entries as they are fetched and that evicted entries are preserved in the cluster instead of lost.

Additionally, eviction strategies can be used as required for your configuration to set up which entries are evicted and when eviction occurs.

See also: Eviction and Expiration Comparison

2.2. Eviction Strategies

2.2.1. Eviction Strategies

Each eviction strategy has specific benefits and use cases, as outlined below:

Table 2.1. Eviction Strategies

Strategy NameOperationsDetails

EvictionStrategy.NONE

No eviction occurs.

This is the default eviction strategy in Red Hat JBoss Data Grid.

EvictionStrategy.LRU

Least Recently Used eviction strategy. This strategy evicts entries that have not been used for the longest period. This ensures that entries that are reused periodically remain in memory.

 

EvictionStrategy.UNORDERED

Unordered eviction strategy. This strategy evicts entries without any ordered algorithm and may therefore evict entries that are required later. However, this strategy saves resources because no algorithm related calculations are required before eviction.

This strategy is recommended for testing purposes and not for a real work implementation.

EvictionStrategy.LIRS

Low Inter-Reference Recency Set eviction strategy.

LIRS is an eviction algorithm that suits a large variety of production use cases.

2.2.2. LRU Eviction Algorithm Limitations

In the Least Recently Used (LRU) eviction algorithm, the least recently used entry is evicted first. The entry that has not been accessed the longest gets evicted first from the cache. However, LRU eviction algorithm sometimes does not perform optimally in cases of weak access locality. The weak access locality is a technical term used for entries which are put in the cache and not accessed for a long time and entries to be accessed soonest are replaced. In such cases, problems such as the following can appear:

  • Single use access entries are not replaced in time.
  • Entries that are accessed first are unnecessarily replaced.

2.3. Using Eviction

2.3.1. Using Eviction

In Red Hat JBoss Data Grid, eviction is disabled by default. If an empty eviction / element is used to enable eviction without any strategy or maximum entries settings, the following default values are used:

  • Strategy: If no eviction strategy is specified, EvictionStrategy.NONE is assumed as a default.
  • size: If no value is specified, the size value is set to -1, which allows unlimited entries.

2.3.2. Initialize Eviction

To initialize eviction, set the eviction element’s size attributes value to a number greater than zero. Adjust the value set for size to discover the optimal value for your configuration. It is important to remember that if too large a value is set for size, Red Hat JBoss Data Grid runs out of memory.

The following procedure outlines the steps to initialize eviction in JBoss Data Grid:

Initialize Eviction

  1. Add the Eviction Tag

    Add the eviction tag to your project’s cache tags as follows: 

    <eviction />

  2. Set the Eviction Strategy

    Set the strategy value to set the eviction strategy employed. Possible values are LRU, UNORDERED and LIRS (or NONE if no eviction is required). The following is an example of this step: 

    <eviction strategy="LRU" />

  3. Set the Maximum Size to use for Eviction

    Set the maximum number of entries allowed in memory by defining the size element. The default value is -1 for unlimited entries. The following demonstrates this step: 

    <eviction strategy="LRU" size="200" />

2.3.3. Eviction Configuration Examples

Eviction may be configured in Red Hat JBoss Data Grid programmatically or via the XML file. Eviction configuration is done on a per-cache basis.

A sample XML configuration for is as follows: 

<eviction strategy="LRU" size="2000"/>

2.3.4. Utilizing Memory Based Eviction

Red Hat JBoss Data Grid 7 introduced memory based eviction, allowing eviction of entries based on memory usage of the entries instead of the number of entries. This can be particularly useful if the entries vary in size.

Key/Value Limitations

Only keys and values that are stored as primitives, primitive wrappers (such as java.lang.Integer), java.lang.String instances, or an Array of these values may be used with memory based eviction.

Due to this limitation if custom classes are used then either store-as-binary must be enabled on the cache, or the data from the custom class may be serialized, storing it in a byte array.

Compatibility mode prevents serialization into byte arrays, and as such these two features are mutually exclusive.

Eviction Strategy Limitations

Memory based eviction is only supported with the LRU eviction strategy.

Enabling Memory Based Eviction

This eviction method may be used by defining MEMORY as the eviction type, as seen in the following example: 

<local-cache name="local">
    <eviction size="10000000000" strategy="LRU" type="MEMORY"/>
</local-cache>

2.3.5. Eviction and Passivation

To ensure that a single copy of an entry remains, either in memory or in a cache store, use passivation in conjunction with eviction.

The primary reason to use passivation instead of a normal cache store is that updating entries require less resources when passivation is in use. This is because passivation does not require an update to the cache store.