What happens when we reach our limits?

As large as we might be able to scale a cluster to handle the ever-growing datasets, it is quite possible that we will want to configure a map so that it features a specific behavior. The things that we can customize are the number of backup counts and types, limits on how big a particular map can grow, plus what we can do when we reach that limit, and the defining of a default lifespan for the entries. We can use the hazelcast.xml configuration to define this behavior for all the maps or for an inpidual one. Now, we can copy the configuration from the unpacked download bin/hazelcast.xml to our working directory, which should be on the Java classpath, and add a custom configuration for the capitals map, as follows:

<map name="capitals">

  <max-size policy="PER_NODE">10</max-size>
  <eviction-policy>LFU</eviction-policy>
  <eviction-percentage>20</eviction-percentage>

  <backup-count>1</backup-count>
  <async-backup-count>1</async-backup-count>

  <time-to-live-seconds>86400</time-to-live-seconds>
  <max-idle-seconds>3600</max-idle-seconds>

</map>

The properties that we have put in place should all be relatively self-explanatory, but let's go through them in a little more detail, as there are a few properties that demand closer inspection. The first set deals with bounding the size of the map and what to do when the limit of the map is reached.

The max-size parameter, as you would expect, governs how big a map can grow before we have a clear out and evict the existing entries to make room for the potential ones that may be created in the future. However, we can additionally pick any of the six types of policies to vary this behavior.

The first (and the default) policy is the easiest to understand:

• PER_NODE
  • The maximum number of entries per node

The second one is probably the least useful in a real-world scenario.

• PER_PARTITION
  • The maximum number of entries per internal partition slice
  • The number of partitions is also configurable, but as a cluster-wide parameter rather than something that is specific to any one map

The latter policies are related to the usage of an inpidual node's heap.

• USED_HEAP_SIZE
  • The maximum heap usage in megabytes
• USED_HEAP_PERCENTAGE
  • The maximum proportion of the total heap size
• FREE_HEAP_SIZE
  • The minimum heap usage in megabytes (the inverse of the above)
• FREE_HEAP_PERCENTAGE
  • The minimum proportion of the total heap size (the inverse of the above)

The eviction-policy governs the strategy that is used to select the entries that should be discarded when making room for the new ones. There are a few options to pick from:

• NONE
  • No eviction (default)
• Least Recently Used (LRU)
  • The oldest interacted with entries
• Least Frequency Used (LFU)
  • The least interacted with entries

The eviction-percentage dictates when we trigger an eviction and how much space we preemptively need to create relative to the overall max-size of the map.

The next set of configurations deals with the backup copies of entries, both in terms of the number of duplicate copies to hold as well as the method and consistency of how they are created.

• The backup-count controls the number of backup copies that can be created synchronously on each change. Increasing this number significantly will have performance implications, as update operations will have to block awaiting receipt of confirmations from this many of backup nodes.
• The async-backup-count controls the number of backup copies that are created asynchronously on a best-efforts basis. This figure, combined with the backup-count, determines the total number of backup copies that should be held.

The final set is used to set a map-wide default TTL for entries:

• The time-to-live-seconds is a default dumb TTL for each entry. Entities will be removed from the map after this amount of time, irrespective of use or resetting when overwritten.
• The max-idle-seconds sets the maximum time that an entry can remain unused before it expires.