This document is DEPRECATED.

Please consider any information here as out of date. DO NOT use this document.

Instead, refer to

Please update your bookmarks accordingly.

Skip to end of metadata
Go to start of metadata

Infinispan supports eviction of entries, such that you do not run out of memory.  Eviction is typically used in conjunction with a cache store, so that entries are not permanently lost when evicted, since eviction only removes entries from memory and not from cache stores or the rest of the cluster.

Passivation is also a popular option when using eviction, so that only a single copy of an entry is maintained - either in memory or in a cache store, but not both. The main benefit of using passivation over a regular cache store is that updates to entries which exist in memory are cheaper since the update doesn't need to be made to the cache store as well.

Note that eviction occurs on a local basis, and is not cluster-wide.  Each node runs an eviction thread to analyse the contents of its in-memory container and decide what to evict. Eviction does not take into account the amount of free memory in the JVM as threshold to  starts evicting entries. You have to set maxEntries attribute of the eviction element to be greater than zero in order for eviction to be turned on. If maxEntries is too large you can run out of memory. maxEntries attribute will probably take some tuning in each use case.

Eviction in 5.2

Eviction is configured by adding the <eviction /> element to your <default /> or <namedCache /> configuration sections or using EvictionConfigurationBuilder API programmatic approach. LIRS is default eviction algorithm in Infinispan 5.2 release.

All cache entry are evicted by piggybacking on user threads that are hitting the cache. Periodic pruning of expired cache entries from cache is done on a dedicated thread which is turned on by enabling reaper in expiration configuration element/API.


This eviction strategy effectively disables the eviction thread.


UNORDERED eviction strategy is a legacy eviction strategy that has been deprecated. If UNORDERED strategy is specified LRU eviction algorithm will be used.


If LRU eviction is used cache entries are selected for eviction using a well known least-recently-used pattern.


LRU eviction algorithm, although simple and easy to understand, under performs in cases of weak access locality (one time access entries are not timely replaced, entries to be accessed soonest are unfortunately replaced, and so on). Recently, a new eviction algorithm - LIRS has gathered a lot of attention because it addresses weak access locality shortcomings of LRU yet it retains LRU's simplicity. Eviction in LIRS algorithm relies on history information of cache entries accesses using so called Inter-Reference Recency (a.k.a IRR) and the Recency. The IRR of a cache entry A refers to number of other distinct entries accessed between the last two consecutive accesses to cache entry A, while recency refers to the number of other entries accessed from last reference to A up to current time point. If we relied only on cache recency we would essentially have LRU functionality. However, in addition to recency LIRS tracks elements that are in low IRR and high IRR, aptly named LIR and HIR cache entry blocks respectively. LIRS eviction algorithm essentially keeps entries with a low IRR in the cache as much as possible while evicting high IRR entries if eviction is required. If recency of a LIR cache entry increases to a certain point and entry in HIR gets accessed at a smaller recency than that of the LIR entry, the LIR/HIR statuses of the two blocks are switched. Entries in HIR may be evicted regardless of its recency, even if element was recently accessed.

Configuration and defaults in 5.2.x

By default when no <eviction> element is specified, no eviction takes place.

In case there is an eviction element, this table describes behaviour of eviction based on information provided in the xml configuration ("-" in Supplied maxEntries or Supplied strategy column means that the attribute wasn't supplied)

Supplied maxEntries Supplied strategy Example Eviction behaviour
- - <eviction />
no eviction
> 0 - <eviction maxEntries="100" />
the strategy defaults to LIRS and eviction takes place
> 0 NONE <eviction maxEntries="100" strategy="NONE" />
the strategy defaults to LIRS and eviction takes place
> 0 != NONE
<eviction maxEntries="100" strategy="LRU" />
eviction takes place with defined strategy
0 - <eviction maxEntries="0" />
no eviction
<eviction maxEntries="0" strategy="NONE" />
no eviction
0 != NONE
<eviction maxEntries="0" strategy="LRU" />
< 0 - <eviction maxEntries="-1" />
no eviction
< 0 NONE
<eviction maxEntries="-1" strategy="NONE" />
no eviction
< 0 != NONE
<eviction maxEntries="-1" strategy="LRU" />

Advanced Eviction Internals

Implementing eviction in a scalable, low lock contention approach while at the same time doing meaningful selection of entries for eviction is not an easy feat. Data container needs to be locked until appropriate eviction entries are selected. Having such a lock protected data container in turn causes high lock contention offsetting any eviction precision gained by sophisticated eviction algorithms. In order to get superior throughput while retaining high eviction precision both low lock contention data container and high precision eviction algorithm implementation are needed. Infinispan evicts entries from cache on a segment level (segments similar to ConcurrentHashMap), once segment is full entries are evicted according to eviction algorithm. However, there are two drawbacks with this approach. Entries might get evicted from cache even though maxEntries has not been reached yet and maxEntries is a theoretical limit for cache size but in practical terms it will be slightly less than maxEntries. For more details refer to Infinispan eviction design.


Similar to, but unlike eviction, is expiration. Expiration allows you to attach lifespan and/or maximum idle times to entries. Entries that exceed these times are treated as invalid and are removed. When removed expired entries are not passivated like evicted entries (if passivation is turned on).

Unlike eviction, expired entries are removed globally - from memory, cache stores, and cluster-wide.

By default entries created are immortal and do not have a lifespan or maximum idle time.  Using the cache API, mortal entries can be created with lfiespans and/or maximum idle times.  Further, default lifespans and/or maximum idle times can be configured by adding the <expiration /> element to your <default /> or <namedCache /> configuration sections.

Difference between Eviction and Expiration

Both Eviction and Expiration are means of cleaning the cache of unused entries and thus guarding the heap against OutOfMemory exceptions, so now a brief explanation of the difference.

With eviction you set maximal number of entries you want to keep in the cache and if this limit is exceeded, some candidates are found to be removed according to a choosen eviction strategy (LRU, LIRS, etc...). Eviction can be setup to work with passivation (evicting to a cache store).

With expiration you set time criteria for entries, how long you want to keep them in cache. Either you set maximum lifespan of the entry - time it is allowed to stay in the cache or maximum idle time, time it's allowed to be untouched (no operation performed with given key).

infinispan infinispan Delete
configuration configuration Delete
eviction eviction Delete
out_of_memory out_of_memory Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.