What happens when we reach our limits?

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

<map name="capitals">

  <max-size policy="cluster_wide_map_size">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 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 that demand closer inspection.

The first set deals with bounding the size of the map and what to do when that limit is reached.

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

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

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

The latter three policies relate to the usage on an individual node basis.

eviction-policy governs the strategy used to select entries to discard when making room for new ones; there are few options to pick from.

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 deal with backup copies of entries both in terms of number of duplicate copies to hold, but also the method and consistency of how they are created.

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