Monday, August 31, 2020

Latency for sharing data while using Hazelcast on Virtual Machine


A few days back we found out one old app which was running on multiple nodes while having in-memory cache usage. So, as a result, there was a case when the request came to the first node and the second node didn't get that data, and the app wasn't functioning properly. 

So, as always first thing which we considered to use Redis. However, we don't have ready to use the Redis cluster and we started looking for other solutions in a market. Finally, I saw there is a Hazelcast which allows sharing data between nodes even without having the Hazelcast cluster. Of course, it is working when you are running in the same network. So, nodes should be able to multicast and make a proper cluster.

Of course, I was happy with a solution while checking locally it was working like magic, everything was fine for testing in a laptop with multiple running instances. But, when I pushed my changed to TEST environment headache started :) When I pushed the data to a node it was able to sync with other nodes. However, when I shutdown one node and return it back Hazelcast wasn't able to join that node to cluster (not shared the data with that node) at least 2-3 minutes. So, I was experimenting with multiple configs to achieve it.

NO LUCK... I decided to ask my question in a StackOverflow because wasn't able to find anything useful while googling. And before publishing my question StackOverflow suggested me to check some posts, while checking them one by one I found a question in a Hazelcast's git page. One guy was asking why they are using "224.2.2.3" as a default Multicast Group. So, he said he is running in a VM and having similar problem as mine. He mentioned when he changes the default group to "224.0.0.1" it works for him. So, I decided to give a try and it worked :D

So, if somebody has a similar problem, please change the multicast default group as below and retry:

Config config = Config.load().setClusterName(CLUSTER_NAME);
config.getNetworkConfig().getJoin().getMulticastConfig().setMulticastGroup("224.0.0.1");
hazelcastInstance = Hazelcast.newHazelcastInstance(config);

5 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Every caching solution that runs on a Java Virtual Machine (JVM) has to deal with the perilous problems of garbage collection (GC) caused by storing data in the memory. Modern hardware has much more available memory. If you want to make use of that hardware to scale up by specifying larger heap sizes, GC becomes an increasing problem: the application faces long GC pauses that make the application performance unresponsive and unpredictable. Simply put, the problem of GC pauses gets more serious as the size of heap increases: the larger the heap, the longer it takes JVM to finish stop-the-world full GC cycle.

    Custom Medicine Boxes

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Welcome to the world of Natural

    Herbs Clinic
    where you can find a range of Herbal Remedies for almost

    every ailment vacillating from mild or chronic. This is a complete online

    herbal remedy store where we not just sell herbal alternative medicines for

    the sake of coining profit but we put our client’s consummation and well-

    being prior to our business.

    ReplyDelete