Hazelcast blasts pass competitors in performance, as measured by their own tools!

We should start calling Hazelcast, Hazelfast. Hazelcast 3.6 EA shipped last week, and it is very fast. Compared to what, you ask? Well, compared to everything. How do we know this? Well, our competitors made their own comparative benchmarking tools, YardStick and RadarGun. And we ran them against Hazelcast as we were developing 3.6. We were getting faster anyway thanks to our dedicated performance team, but there is nothing like competition to spur improvement.

Hazelcast versus Infinispan/JBoss Data Grid

On RadarGun, the Infinispan tool, we are faster in all tests with the biggest margin begin 80%.

See the full benchmark results here.

Source code for the benchmark is here: See the results of the Radar-Gun Benchmark https://github.com/Danny-Hazelcast/radargun.

Hazelcast versus Apache Ignite/GridGain

On YardStick, the GridGain tool, we are faster in all tests with the biggest margin being 90% faster.

Source code for each benchmark is on GitHub:

See the full benchmark here.

Oracle Coherence

It turns out that it is a breach of Oracle’s OTN license to publish benchmarks. So we can’t comment at all on our benchmark results compared to Oracle Coherence. But, there is no such restriction on publishing a Benchmark Suite. We can send it to you and you can run it yourself.

Hazelcast 3.2.2 Released

We just released Hazelcast 3.2.2. This release is a stable, production-ready maintenance release.

Stabilizer Testing

This release was tested using our new production simulator, Hazelcast Stabilizer for 48 hours with the following configurations:

small       = [12 instance, memberWorkerCount 4, clientWorkerCount 8]
medium  = [26 instance, memberWorkerCount 6, clientWorkerCount 20]
large       = [50 instance, memberWorkerCount 10, clientWorkerCount 40]

This first one just used the MapTest, but on the next release we will include more.

Patch Release 3.2.2 – Closed Issues


Hazelcast 3.3-EA Released

We just released Hazelcast-3.3-EA with the following new features:

  • Heartbeat for Java client
  • filterless Tomcat 6&7 Web Sessions Clustering (Enterprise only)
  • Enterprise WAN Replication (Enterprise only)
  • Replicated Map

Download Enterprise version here or open source version here.

We anticipate the RC version will be out mid-June.


How JSR107 Caching Annotations are meant to be used

I am getting a few questions lately on JSR107 caching annotations and whether implementations of JSR107 are providing them.
Caching annotations can be added to your Java classes and will invoke caching operations as the method. For example below is an annotated BlogManager.
@CacheDefaults(cacheName = "blgMngr")
public class BlogManagerImpl implements BlogManager {private static Map<String, Blog> map = new HashMap<String, Blog>();@CacheResult
public Blog getEntryCached(String title) {
return map.get(title);

public Blog getEntryRaw(String title) {
return map.get(title);

* @see manager.BlogManager#clearEntryFromCache(java.lang.String)
public void clearEntryFromCache(String title) {

public void clearEntry(String title) {
map.put(title, null);

public void clearCache() {

public void createEntry(Blog blog) {
map.put(blog.getTitle(), blog);

public Blog getEntryCached(String randomArg, @CacheKey String title,
String randomArg2) {
return map.get(title);

Caching annotations, though defined in JSR107, are not meant to be provided by a CachingProvider such as Hazelcast. Instead they must be provided by the dependency injection containers: Spring, Guice, CDI (for Java EE). This will happen with EE in 8 which is a couple of years away. Spring support is coming in 4.1 and is available now for developers to play with in snapshot. See https://spring.io/blog/2014/04/14/cache-abstraction-jcache-jsr-107-annotations-support for how to use it.
While it will take time for the DIs to add support, in the JSR107 RI we have written a module for each of them. That code can be added to your existing DI Container and it will enable caching annotations processing. See https://github.com/jsr107/RI/tree/master/cache-annotations-ri.

I will be joining Hazelcast as CTO

I am very excited to announce that I will be joining the world-class team at Hazelcast as CTO.

Hazelcast (www.hazelcast.com) develops, distributes and supports the leading open source in-memory data grid. The product, also called Hazelcast, is a free open source download under the Apache license that any developer can include in minutes to enable them to build elegantly simple mission-critical, transactional, and terascale in-memory applications. The company provides commercially licensed Enterprise extensions, Hazelcast Management Console and professional open source training, development support and deployment support. The company is privately held and headquartered in Palo Alto, California.

What this means for Hazelcast Users

I will join my efforts to those of Hazelcast CEO Talip Ozturk and the team and bring my deep knowledge of caching to Hazlecast to complement that of the team. I will be out and about at conferences and visiting customers.

With the team we will be figuring out what great features to add to Hazelcast and how to improve the leading open source In-Memory Data Grid.

We will also be bring to market Enterprise Extensions which add high value features based around the Hazelcast core.

Hazelcast has made an announcement that puts this move into their own words.

What this means for Terracotta BigMemory Users

We will develop a comparative caching/operational store project and product based on Hazelcast core.   This will then be an alternative for BigMemory users.

What this means for Ehcache Users

The ownership of Ehcache was transferred to Terracotta 4 and a half years ago when I joined them who then took over maintenance of it.

While Ehcache remains widely used today, the open source version is only suitable for single node caching. This is not that useful for most production contexts so it is not directly competitive with Hazelcast or for that matter In-Memory Data Grids, which deal with clusters of computers.

I expect Ehcache will implement JCache and that in the future those ISVs and open source frameworks which currently define Ehcache as their caching layer will instead define it using JCache, of which Ehcache will be one provider.

Hazelcast is already developing their JCache implementation, which is already up on GitHub.

What this means for JCache

JCache is the new standard for caches and IMDGs. It includes a key-value API suitable for caches and operational stores. Importantly it was designed primarily for IMDGs. Listeners, loaders, writers and other user-defined classes are expected to be executed somewhere in the cluster, not in process.  And the spec defines and single and batch EntryProcessors, the defining feature of IMDG, which enables in-situ computation.

I will continue to act as spec lead on new maintenance releases of JCache. And I will also work with the Java EE 8 expert group who are including JCache in Java EE8. And I will be working with open source frameworks and ISVs as they move to add a JCache layer to their architectures.

Hazelcast will be one of the first to market with an implementation of JCache which should be available in a production-ready implementation in February.

As it is Apache 2 open source, I encourage open source frameworks and ISVs to include Hazelcast in their distributions as they add JCache. That way they can ship with an out of the box IMDG built in without locking themselves or their users/customers into a single vendor.