Hazelcast is an in-memory data grid (IMDG) that provides distributed data management capabilities. One of its fundamental features is the ability to store, manage, and evict entries from distributed maps (known as IMap). Understanding how Hazelcast performses map entry eviction is vital for optimizing application performance and resource management.

Overview of Eviction in Hazelcast

In Hazelcast, map entry eviction is the process of automatically removing entries from a map when certain criteria are met. This is typically done to manage memory consumption effectively. Eviction can be driven by various policies such as Least Recently Used (LRU), Least Frequently Used (LFU), and a time-based (TTL) policy. The configuration of these policies is highly customizable, allowing fine-tuning based on specific application requirements.

Threading Model of Eviction

Hazelcast employs a sophisticated threading model to handle the eviction process. The model is built around the concept of partitions and partition threads. Here’s how it works:

1. Partition Division: The data in a Hazelcast cluster is divided into multiple partitions. Each partition is hosted on a cluster member.
2. Partition Threads: Each member uses multiple threads to manage its partitions independently. These threads are responsible for all operations related to their respective partitions, including entry processing, addition, deletion, and eviction.
3. Eviction Operation: Eviction operates at the partition level and is managed by the partition thread. This means that eviction on one partition does not block operations on another. Each partition thread independently checks and evicts entries based on the configured eviction policy.

Eviction Triggers

The actual process of eviction can be triggered in several ways:

• Size-based Eviction: When the size of the map exceeds a specified threshold. The configured eviction policy determines which entries to remove.
• Time-to-live (TTL) Eviction: Entries can be configured with a TTL value. When the TTL expires, the entry is automatically removed during the next access or by a background process.
• Idle Time (MaxIdleSeconds) Eviction: Similar to TTL, but the time counter resets each time the entry is accessed.

Eviction Process

When an eviction is triggered, the partition thread performs the following steps:

1. Selection of Entries for Eviction: Based on the eviction policy (e.g., LRU, LFU), the partition thread selects the entry or entries to be evicted.
2. Safe Eviction: The system ensures that the eviction process does not violate data integrity or consistency. For instance, operations that are currently reading or writing the entry being evicted are properly handled to prevent data corruption.
3. Eviction Execution: The selected entries are removed from the map and their resources are reclaimed.

Example Configuration

An example configuration of an eviction policy in an Hazelcast IMDG's hazelcast.xml file might look like the following:

1<map name="dataMap">
2    <max-size policy="FREE_HEAP_SIZE" value="200m"/>
3    <eviction-policy>LRU</eviction-policy>
4    <time-to-live-seconds>3600</time-to-live-seconds>
5</map>

This configuration defines an LRU eviction policy for dataMap, with a maximum size of 200 MB of free heap space, and a TTL of 3600 seconds.

Summary Table

Conclusion

Hazelcast's map entry eviction is a well-orchestrated process designed to be efficiently scalable by leveraging a partitioned threading model. This model ensures high performance and reliability across the cluster, making Hazelcast a powerful tool for handling distributed data in real-time applications. Understanding and configuring eviction properly can greatly enhance an application's performance and efficient resource management.