Announcing Hazelcast 3.7 General Availability

Enes Akar | Aug 22, 2016

I am really proud to introduce this latest “go-to” release of Hazelcast. So much testing and very high standards mean that each release is a major milestone.

With this release, we have made major structural improvements such as the full realization of our modularization strategy and really significant performance increases- 30% faster than Hazelcast 3.6. Which is a big deal when you are already the fastest in-memory data grid in the market. But that isn’t the end of story.

In terms of modularization, we have separate repos, maven modules and release cycles for many aspects of Hazelcast now. Each client/language and plugin is now a module. When you download a 3.7 distribution, it contains the latest released version. But we can release updates, new features and bug fixes much faster than the Hazelcast core. When we say in this blog we will release something parallel to 3.7, we mean we are releasing a module. And it speeds up development. And of course it is easier to contribute to as an open source contributor.

Hazelcast 3.7 is also the realization of our “any application, in any cloud, anytime” strategy. We’ve provided in this release native integrations with the two leading PaaSes Cloud Foundry and OpenShift which pair perfectly with our host of modular cloud discovery and management plugins to give companies a complete deployment platform for any cloud, any landscape. Matter of fact, many ISVs and companies are finding Hazelcast an irresistible pathway for pursuing their devops-based microservices strategy and it all comes down to the core simplicity and flexibility of Hazelcast that allows it to play a critical infrastructure role without an imposing overhead.

Lastly, the client protocol we introduced in 3.6 is yielding results: we just released supported versions of of the Python and Node.js clients. What’s even more exciting: we see our user community is starting to experiment with the protocol and they are building independent clients. This is Open Source at its best and we love it!

Hazelcast 3.7 is a publicly available release in the Maven repositories and at our downloads page.

There have also been a number of feature improvements which I will cover here as well.

New Features:

Custom eviction policies: In Hazelcast you could always set an eviction policy from one of LRU or LFU. But what if you want more flexibility to suit custom requirements of your app. Custom eviction policy exactly helps on that. We implemented a custom eviction both for our Map and JCache implementations. Here you can see an example of an odd-based evictor. It works with our O(1) probabilistic evictors. You simply provide a comparator and we choose the best eviction candidate.

    * Odd evictor tries to evict odd keys first.
   private static class OddEvictor extends MapEvictionPolicy {

       public int compare(EntryView o1, EntryView o2) {
           Integer key = (Integer) o1.getKey();
           if (key % 2 != 0) {
               return -1;

           return 1;

See the complete code sample here.

Fault-Tolerant ExecutorService: Imagine you send executables to Hazelcast nodes and they take hours to complete. What if one the nodes crashes and you do not know whether the task completed or not? In 3.7, we introduce DurableExecutorService~. It guaranteesexecute at least oncesemantics. Its API is a narrowing ofIExecutorService~. Unlike IExecutorService, users will not be able to submit/execute tasks to selected member/members.

Zone Aware Partition Groups: Hazelcast will provide availability zone aware partition groups configuration (AWS). Also partition grouping will be provided for Azure failure domains and for Availability Zones when available. To ensure that real redundancy is provided, the backups are located in the other Zone. High availability is provided in this way.

New Cloud Integrations: We are releasing the CloudFoundry and OpenShift plugins parallel to the 3.7 release. The Hazelcast members deployed to CloudFoundry and OpenShift will discover each other automatically. Also you will have an option to connect and use Hazelcast as a service inside CloudFoundry and OpenShift. You also have the option of using this with Docker – See Rahul’s following blog to learn more about using the CloudFoundry Integration.

We also released our Azure Cloud Discovery Plugin for running Hazelcast on Azure. Hazelcast was also be up in Microsoft Azure Marketplace by the end of June. Look out for the forthcoming blog on that.

Apache Spark Connector: Parallel to the 3.7 release we are releasing our new plugin Hazelcast-Spark connector. It allows Hazelcast Maps and Caches to be used as shared RDD caches by Spark using the Spark RDD API as per the following cache example.

// read from cache
HazelcastJavaRDD rddFromCache = hsc.fromHazelcastCache("cache-name-to-be-loaded")

JavaPairRDD<Object, Long> rdd = hsc.parallelize(new ArrayList<Object>() {{

// write to cache

Both Java and Scala Spark APIs are supported. See the module repo for details.

Reactive – We did the hard work of adding back pressure to Hazelcast over the 3.5 and 3.6 releases. Hazelcast internally is fully asynchronous. Now we are beginning to expose reactive methods. In 3.7 most of the IMAP async methods plus AsyncAtomicLong have been added. Vert.x-Hazelcast is a very popular combination. Vert.x 3.3.0-CR2 has the new reactive Hazelcast integration for much higher performance. The reactive methods return ICompletableFuture which can accept a callback allowing a reactive style.

WAN Replication Enhancements (Enterprise Only): With 3.7; we implemented the ability to resynchronize a remote WAN cluster. This was implemented for IMap (Cache implementation is left for 3.8). This is very useful when you initiate a WAN connection or need to reinitiate after maintenance to a remote cluster.

WAN Replication via Solace (Enterprise Only): We also added WAN replication with Solace, a high performance enterprise grade messaging solution.

Notable Improvements in Hazelcast internals

This release in particular focused on some deep plumbing to fix some rare edge cases in Hazelcast to improve correctness. For those of you who like to read about gory details I cherry-picked a few notable changes:

  • Improvements on partitioning system: Our community had detected the following issue: During a migration process, there can happen a moment that data is kept by number of nodes which is less than the configured backup count even there is enough number of nodes in the cluster. If any node crashes at this unfortunate moment, we were losing data. Although, some may claim this is an edge case scenario; still it was conflict with our guarantee that we give to our users. So we designed and implemented major improvements in our partitioning and migration system. You can find a detailed explanation of the solution here:
  • Graceful shutdown improvements: We need to ensure data safety while shutting down multiple nodes concurrently. But there was a counter example: When a node shuts down, it checks if all 1st backups of its partitions are synced without checking if the backup node is also shutting down or not. There is a race situation here. If both owner and backup nodes shutdown at the same time, we lose data since owner is not aware that 1st backup is also shutting down. See the following PR to get an idea about the solution:
  • Improvement to the threading model: In 3.7, there is now at least 1 generic priority thread that will only process generic priority operations like member/client heartbeats. This means that under load the cluster remains more stable since these important operations get processed. See following PR for details of the problem and solution:
  • Improvements to the invocation system: Invocation service is one of the parts that we were wanting to improve and simplify. Because it is complex, it was hard to fix bugs, even minor changes were prone to regressions. We simplified the invocation logic and fixed some ambiguities. Although it is a completely internal development, it has made Hazelcast more stable preventing many problems regarding invocation system. Relatedly various enhancements (e.g. moving IsExecutingOperation into its own thread) fixed several issues like the following:
  • Performance improvement on map.putAll(): We introduced grouping and batching of remote invocations but also reduced some internal litter for higher performance. Our efforts resulted in a performance gain up to 15% especially when the argument size is bigger. If you want to read some code, here it is:
  • Prevent blocking reads in transactions: To provide atomicity for transactions, we were blocking the reads on entries which are locked transactionally. This is not an optimized solution. We changed the architecture so that we block reads just before the commit.
  • Improvements on Hot Restart and HD (Enterprise HD Only): We introduced batching of hot restart operations (when fsync is enabled) that will improve performance notably. Moreover, we optimized memory usage of Hot Restart by persisting values to disk, reducing metadata. In high density memory, we created an abstraction layer for safer memory access which also handled unaligned memory access to enable HD on Oracle Sparc CPUs commonly found in Solaris systems.
  • .NET Client Enhancements: Besides working on new clients, our team is enhancing existing clients. We added predicate and SSL support for our .Net client.

New Clients

After publishing the client protocol in 3.6 and with support of our community, we started working on new native clients. Happily Python and Node.js clients have now been released as support clients. See our new clients page to see our list of clients and features implemented in each.

Closing Words

We always need your help, please try 3.7 and create issues you encounter. You can use our forum, Twitter (@hazelcast) or Stackoverflow for your questions; and Github for your bug reports and contributions.

Thank you all for your support.

Relevant Resources

View All Resources
About the Author

Enes Akar

Co-founder & CTO, Hazelcast Cloud

Enes was one of the early developers of Hazelcast. He joined the company in 2011 with a passion for making distributed computing incredible simple. From 2012 to 2017, he headed the engineering team as VP of Engineering. Since 2017, he has led the development of Hazelcast Cloud, which is enterprise-grade Hazelcast software as a fully managed service in the cloud. Prior to joining Hazelcast, Enes worked in software development and software engineering at telecommunications companies, including Alcatel-Lucent and Ericsson. He holds a Bachelor of Science in Computer Engineering and an MBA from Bogazici University, Istanbul.