Fully replicated map for cluster

[Sunz]

I am using hazelcast for hibernate second level cache. I need the data to be fully replicated across the cluster. I am using the (backup-count, async-backup-count) as (1,0). This suffices a two node cluster. The cached data in both the nodes is same.

Now, I need to make this as an 8 node cluster. I see that the max config supported is (backup-count, async-backup-count) = (6,0) or (0,6).

1. Is there a reason for this limitation?

2. In this setup of (0,6) will all the nodes have the same data in cache?

3. Is there a way to increase this to (0,8).

4. How else do we achieve 8 node cluster config and have same data in all nodes.

Regards

[Sunz]

I see that ECache supports this. Does Hazelcast support it too. Need this information to decide. Could someone let me know...

[Rahul Gupta]

Hazelcast has a feature called ReplicatedMap. Here is a sample config:

Note: ReplicatedMap != backed up map. Replicated Map means all nodes will have the same map contents but this has its own overheads - ReplicatedMap is weakly consistent i.e. replication is done on best efforts basis. Another side effect of ReplicatedMap is high heap consumption - the data is not partitioned across the cluster i.e. all map contents will be stored locally, on all nodes; which results in high memory consumption.

ReplicatedMap makes sense when your application has the tolerance of reading stale data and latency requirements are very tight. ReplicatedMap are super fast - all nodes have all the data, so no network hopping for reading. Writes happen locally and eventually replicated across all nodes.

One ques - what is stopping you from having a backed up map? The reason for keeping the backup count max to 6 is that very rarely you would need a higher backup count than 2 or 3. If you need a higher backup count i.e. more backup nodes for each node, then that means there is something fundamentally wrong in the infrastructure itself because chances of all the nodes (main + backup) going down in a cluster are usually very low.

Btw, Ehcache supports full replication only when you distribute the cluster. Replicated Ehcache (non-distributed) is known to have many consistency as well as performance issues.

Cheers,

Rahul

[Sunz]

I saw the ReplicatedMap, but I guess it is available as Developer version only.

Anyway, i figured out that i don't need the backup feature nor data replication for my development. I just need to invalidate the cache (hibernate second level) if the value of any <key,value> pair is altered on any one of the systems in the cluster.

For this, I implemented the EntryListener. And I see that I get the events on all of my nodes. Is this the right behaviour?

I also noticed that the data in the Maps used are identical on these clusters. For now my cluster is of two node.

My questions might be very basic, but i need to understand if this is how the second level cache feature works. Is the Map data updated on all the nodes?

My config is using hazelcast.xml as below:

    <map name="com.one.two.Cache">

        <in-memory-format>BINARY</in-memory-format>

        <backup-count>0</backup-count>

        <async-backup-count>0</async-backup-count>

        <eviction-policy>LRU</eviction-policy>

        <merge-policy>com.hazelcast.map.merge.PassThroughMergePolicy</merge-policy>

        <entry-listeners>

           <entry-listener include-value="true" local="false">com.one.two.CacheEntryListener</entry-listener>

        </entry-listeners>

    </map>

[Rahul Gupta]

I am now confused... would you please explain what exactly are you trying to achieve? If you need to backup your data, you should can set backup-count = some number, and that is good enough.

As I explained previously - 

Replicated data = data replicated on all nodes, i.e. same copy of data on all nodes

Backup data = original data is on main node (the node that was decided by HZ cluster to host the data) and backup on other nodes. In a healthy cluster, the caller thread never interacts with backup node, get/put requests always go to the main hosting node no matter where the mutation call came from.

Does this help?

On Wednesday, July 23, 2014 3:34:38 PM UTC+5:30, Sunz wrote:

[Fuad Malikov]

For H2LC did you try HazelcastLocalRegionFactory? It is a replicated implementation instead of the default distributed behavior.

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at http://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/32d59d6e-f67f-4dfa-af60-5fd6c3f67730%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sunil Sonnad]

I tried HazelcastRegionFactory and got it working. I had tried the hazelcastlocalRegionFactory earlier but had some issues, will try it again. Also need to figure out how different they are.

@Rahul, the feature mentioned under the documentation for HazelcastLocalRegionFactory is what i am looking for...

Regards

---

From: Fuad Malikov
Sent: ‎25-‎07-‎2014 17:36
To: Hazelcast
Subject: Re: Fully replicated map for cluster

You received this message because you are subscribed to a topic in the Google Groups "Hazelcast" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hazelcast/UL8_eqABXx4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hazelcast+...@googlegroups.com.

To post to this group, send email to haze...@googlegroups.com.
Visit this group at http://groups.google.com/group/hazelcast.

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/CABakLExvqMY9RTaveMz93%2Bw3YT7WffzznFikqJGgdGF9AuJDkg%40mail.gmail.com.