Why choose Hazelcast over Infinispan ?

[Olivier Masseau]

Hi,

Well everything is in the question.

We have to decide on a distributed cache implementation.

We currently have a Wildlfy server which ships with Infinispan.

From your experiences, what at the main reasons to use Hazelcast over the already provided Infinispan ?

Thanks a lot ;)

[Jiri Holusa]

Hi!

this is a pretty wide question, so my answer will surely not be complete but I'll try my best.

First of all, you're saying:

> We currently have a Wildlfy server which ships with Infinispan.

While this is absolutely correct, according to the official Red Hat/JBoss documentation, Infinispan is delivered as a private module within Wildfly/EAP and is not supposed to be used directly by the applications. You can find the information here https://access.redhat.com/articles/112673 , quoting "Infinispan is delivered as a private module in EAP to provide the caching capabilities of EAP. Infinispan is not supported for direct use by applications". That being said, the fact that Infinispan is already present in Wildfly should not be considered as a benefit as you are not supposed to use it.

We can therefore come to some feature comparison. I'll take it from the Hazelcast point of view what do we offer extra compared to Infinispan. To be fair, I should disclaim that I'm not an Infinispan expert and there certainly can be functionality or parts that I'm not aware of that Infinispan provides and we don't.

* Distributed datastructures support - Infinispan supports only a small subsets of distributed datastructures that Hazelcast provides. From what I know, Infinispan supports only Maps (in their terminology Caches), Locks, MultiMaps and Counters. Compared to Hazelcast which offers Collections (Map, Queue, PriorityQueue, Set, List, Ringbuffer, MultiMap, ReplicatedMap and Cardinat Estimator), Topics for basic messaging usecases (Topic, ReliableTopic) and distributed concurrency primitives (Locks, AtomicLong, Semaphore, AtomicRefernce, CountDownLatch, PNCounter,) and Event Journal. Reference: https://docs.hazelcast.com/imdg/latest/data-structures/distributed-data-structures.html

* Strong consistency subsystem - Infinispan is purely AP (from the CAP theorem) data grid. Hazelcast is mostly AP as well but it provides strong consistency guarantees for certain datastructures (AtomicLong, Locks) with implementation of the RAFT protocol. This can be handy in cases where you can affort eventual consistency. Reference: https://docs.hazelcast.com/imdg/latest/cp-subsystem/cp-subsystem.html

* SQL support for querying - with Infinispan you have to use the proprietary querying API. With Hazelcast, besides that we have also proprietary querying API called Predicate API (which is going to be superseeded soon), we are heavily investing into standard SQL support. So far, we support basic SELECTs with projections and filters, in 4.2 ORDER BY is coming and we're dedicated to continue investing in it more in 2021 (GROUP BY, JOINs, INSERT, UPDATE ...).  Reference:  https://docs.hazelcast.com/imdg/latest/sql/distributed-sql.html

* Multilanguage support - I'm pretty sure there used to be an Infinispan .NET client but I just can't find it in their documentation. Nevertheless, Hazelcast comes with much wider support of languages other than Java including C#, C++, NodeJS, Python and Go. Reference: https://docs.hazelcast.com/imdg/latest/clients/hazelcast-clients.html

* Ecosystem integrations - according to my knowledge, Infinispan integrates OOTB only with Apache Lucene, Hibernate Search/ORM/OGM and Spring. From the cloud perspective, the integration is focus around OpenShift (which makes sense as a Red Hat's product). Hazelcast offers much wider integration ecosystem including SpringBoot, Quarkus, Microprofile, Micronaut, Hibernate, Tomcat Session Manager, OOTB integration with Kerberos, CDC capabilities via Hazelcast Jet or Striim, Istio Service mesh. More over, we keep the cloud trend on the first place in our mind. Therefore, you'll fine integrations with AWS, GCP, Azure, Kubernetes, OpenShift and VMware Tanzu. Those cloud integrations (mostly discovery plugins) provide OOTB support for forming the clusters in these environments plus extra features specific to them. So imagine that instead of manually configuring the IP address in AWS EC2 with Infinspan and facing a challenge of how to reconfigure it if the instances die, you can leverage automatic EC2 discovery using Hazelcast that will find the other members through a discovery service making elastic clusters in a cloud a piece of cake. Reference: https://guides.hazelcast.org/home/

* Streaming with Hazelcast Jet - our another project called Jet (https://jet-start.sh/) if a fully fledged low-latency streaming engine that plays nicely with Hazelcast IMDG. There's no equivalent like this for Infinispan.

* Managed service - you can try out Hazelcast in our managed service Hazelcast Cloud

=== WARNING: Controversial or subjective ===

* Performance - historically, we knew that Hazelcast was generally faster (reference: https://hazelcast.com/resources/benchmark-infinispan/ ). We did run some internal tests during recent years (the report is pretty old) confirming this. However, since I really want to be fair and I don't want to start any war, I will say that we still *believe* that we're faster in majority of the workloads but I can't show you any official numbers. So take this argument with a grain of salt and don't believe me, test it :)

* Simplicity - this is highly subjective, but from my point of view, Hazelcast is much easier to setup and operate. I will give two specific examples, but again, I'm sure that Infinispan experts would be able to come up with configuration snippets that are obscure in Hazelcast and nice in Infinispan.

Consider setting up a distributed cluster using hardcoded IP addresses. In Infinispan, you have to configure some JGroup stack which consists of low level protocol operations that are part of the networking stack. I have always struggled to understand which one to use, how to configure it. For example a code snippet of TCP stack from the Infinispan documentation (reference: https://infinispan.org/docs/stable/titles/server/server.html#using_jgroups_inheritance-cluster-transport):

```

<jgroups>

   <stack name="my-stack" extends="tcp">

       <TCPGOSSIP initial_hosts="${jgroups.tunnel.gossip_router_hosts:localhost[12001]}" stack.combine="REPLACE" stack.position="MPING" />

       <FD_SOCK stack.combine="REMOVE"/>

       <VERIFY_SUSPECT timeout="2000"/>

       <SYM_ENCRYPT sym_algorithm="AES" keystore_name="mykeystore.p12" keystore_type="PKCS12" store_password="changeit" key_password="changeit" alias="myKey" stack.combine="INSERT_AFTER" stack.position="VERIFY_SUSPECT" />

    </stack>

</jgroups>
```

then specify in in infinispan.xml:
```

<infinispan>

     <jgroups>

         <stack name="my-stack" extends="tcp"> ... </stack>

         <cache-container name="default" statistics="true">

                <transport cluster="${infinispan.cluster.name}" stack="my-stack" node-name="${infinispan.node.name:}"/>

         </cache-container>

      </jgroups>

</infinispan>

```

Compare it to setting up a Hazelcast cluster using TCP (hardcoded IP addresses):

```

<hazelcast>

     <network>

         <join>

              <tcp-ip enabled="true">

                      <member>machine1</member>

                      <member>machine2</member>

               </tcp-ip>

         </join>

      </network>

</hazelcast>

```

Boom, it's working.

Second example, staring a server in an embedded mode, in Infinispan terminology in library mode.

Infinispan:

```

GlobalConfigurationBuilder global = GlobalConfigurationBuilder.defaultClusteredBuilder();

DefaultCacheManager cacheManager = new DefaultCacheManager(global.build());

ConfigurationBuilder builder = new ConfigurationBuilder();

.... configuration

Cache map = cacheManager.getOrCreateCache("myCache", builder.build());

```

Hazelcast:

```

Config config = new Config().

... configuration

HazelcastInstance instance = Hazelcast.newHazelcastInstance(config);

Map map = instance.getMap("myMap");

```

Again, it is highly subjective and I'm aware of that. So again, take it with a grain of salt. But after all, you asked on the Hazelcast forum, so obviously I'm biased :)

I hope that it helps and happy to answer more questions.

Jiri

[Jiri Holusa]

Just an important typo correction in the CP subsystem paragraph - "This can be handy in cases where you can *NOT* affort eventual consistency. "

[David Brimley]

It might have got lost in the middle of that excellent response above, but I'd just like to underline the importance of having a correct CP system serving concurrency primitives.  Locks based on AP systems can be highly problematic especially under network partitions.  Therefore if your systems need that I would recommend Hazelcast over Infinispan.