Hazelcast IMDG 3.11 BETA is Released

Matko Medenjak | Sep 12, 2018

Upcoming Webinar: What’s New in Hazelcast 3.11, November 6th Register Now!  

1,100+ commits merged, 523 pull requests, 148 issues closed, 119 days passed, 41 committers contributed and an another Hazelcast release is out! And here are the updates:

Hazelcast Works on Java 9/10/11

With Hazelcast IMDG 3.11, we are making sure all of our code will be functional with the language features and ecosystem improvements introduced in Java 9, 10 and 11. Our goal is also to support the Jigsaw modular system while keeping Java 6 compatibility.

Hazelcast 3.11 will introduce support by defining automatic modules for our JARs.

Index Statistics

To allow you to fine-tune your application, we have exposed the following statistics for IMap indexes:

  • Index memory cost
  • Average latency for index updates
  • Index hit rate
  • Index query selectivity

Using these statistics, you can determine the efficiency and cost of your indexes and fine-tune the configuration for better query performance.

Exponential Back-off on Client Retry Strategy

We have added a highly configurable back-off strategy for client reconnection attempts. By using this feature, you can configure how clients will try to reconnect to a cluster once a connection is lost. This might be very useful if you have lots of clients and you would like to decrease the pressure on a cluster or have the clients connect at random times. It is also useful if you know the cluster might be unavailable for a longer time so retrying connections at a fixed period is not beneficial.

Untrusted Deserialization Protection

Java deserialization based on java.io.ObjectInputStream class can be vulnerable to different kind of attacks – e.g. remote code execution and DOS attacks.

Hazelcast uses Java serialization methods among other (custom) serialization types. To protect you from untrusted deserialization, we have added deserialization protection based on blacklisting and whitelisting class names and package names.

WAN Replication Sync Using Merkle Trees (Enterprise only)

Clusters connected by WAN can go out-of-sync because of various reasons. Because of this, we have the WAN Replication Sync feature. Currently, Maps in different clusters may be synced only by transferring all entries from the source to the target cluster. This may be inefficient as some entries could be equal on both clusters and do not require to be transferred.

With Hazelcast IMDG 3.11, you can enable Merkle trees as the WAN consistency strategy. This will allow you to detect if two clusters are out-of-sync and to quickly synchronize them by transferring as little data as possible.

Enterprise WAN Replication also now contains more diagnostics so it will be easier to analyze and monitor.

Introducing LOADED Event

So far, loading entries from the Map store produced ADDED events. If you are relying on events and event listeners, this is problematic as you cannot distinguish if an entry was added to the IMap by the user or by loading from the store.

In addition, if you are using WAN Replication, you could encounter two more problems:

  • Entries received by the target cluster would always be persisted
  • If you were populating a Map on the source cluster from a Map store, all entries would be automatically replicated to all target clusters. This would cause lots of network traffic just by initializing a Map.

We have added a new LOADED event and an appropriate entry listener. With this, you can:

  • Distinguish between entries added by the user and loaded from the Map store
  • Exclude entries which are loaded from WAN Replication
  • Not persist entries received by WAN on the target cluster

Ability to Set TTL for Map and Cache Entries

If you are using the IMap or ICache with expiry, in some cases you may need to update the TTL or expiry policy for a specific entry after it has been created. Until now, this was possible only by updating the entry value in addition to updating the TTL. If you wanted to keep the same value, you could have first retrieved the value and then re-send it with the new TTL. Unfortunately, this leaves you open to race conditions.

We have now added new methods on IMap and ICache which don’t require you to provide the entry value when updating the TTL (IMap) or the ExpiryPolicy (ICache).

IMap: Max Idle Timeout per Entry

With the new Hazelcast IMDG release, you can update the max-idle timeout per entry, same way you can for TTL. This way, you can enforce a max-idle timeout per entry different from the one configured by the Map configuration when adding or updating the entry.

New I/O system

We have redesigned the I/O system to avoid blocking or spinning the I/O threads in some cases where a slow client could cause performance problems for the cluster.

JCache – Remove Expired Entries

In JCache, expired records were removed lazily as they were touched. This meant that an entry could stay in-memory indefinitely after being expired and it would consume memory until you try to retrieve the entry.

With Hazelcast IMDG 3.11, we added the capability to periodically remove expired entries. The period is configurable and the expired entries are removed in phases. A phase will scan and handle only a part of the cache records stored in a certain member to avoid introducing performance issues.

Disclaimer and Closing Words

Please download Hazelcast IMDG 3.11-BETA-1 and try it out. We are eager to hear what you think. We do not recommend running Beta versions in production, but we encourage everyone to grab it and play with the new features. We want to hear what you think so please stop by our Gitter channel and Google Group. If you would like to introduce some changes or contribute, please take a look at our or GitHub repository.

Relevant Resources

View All Resources