|Upcoming Webinar: What’s New in Hazelcast 3.11, November 6th Register Now!|
We are pleased to announce the production-ready release of Hazelcast IMDG 3.11. A lot of effort has been put into making this release the most feature complete and the most stable release so far:
- 1,600+ commits merged
- 787 pull requests
- 301 issues closed
- 178 days passed (52 days since BETA)
- 43 committers contributed
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.
In order 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, as well as package names.
WAN Replication Sync Using Merkle Trees (Enterprise only)
Clusters connected by WAN can go out-of-sync for a variety of 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
Up to this point, 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, which allows you to:
- 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 in order to avoid introducing performance issues.
Disclaimer and Closing Words
In addition to the above-mentioned functionalities, countless hours have gone into small improvements, optimizations and community issues, so please download Hazelcast IMDG 3.11 and try it out. 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.