Make DIST acting similar to REPL (RELAY between two clusters)
pedrokowalski Aug 24, 2012 6:25 AMHowdy Guys,
So, I know that we can use JGroup's RELAY protocol to populate changes from one cluster to another. In my case I would like to have cluster C1 with UDP transport, cluster C2 with UDP transport and a TCP bridge created by RELAY. So far so good, but as I've seen Bela's posts and JBoss presentation - RELAY works only for DIST caches, not REPL (at least until RELAY2 will be released).
I wanted to have REPL cache, but if RELAY is not possible for such configuration - I'm wondering - can I achieve somewhat similar functionality of REPL with DIST? I mean, I can set a high numOwners so I'll make sure that the cache entry is populated in at least numOwners nodes. If I use TopologyAwareConsistentHash, I will make sure that these nodes are in both clusters.
Now I will have two types of nodes - server-nodes and client-nodes where server-nodes are cache stores and client-nodes are not. To make the DIST clustering mode act like a REPL I will need to make sure that the data is stored in at least one of the server-nodes to make sure it will be saved in persistent storage - am I right?
Consider this - without any additional changes, if I'll have:
C1 = {A, B, C, D}
C2 = {X, Y, Z, V}
TCP bridge created from {D, V}, cluster mode DIST, numOwners=2
client-nodes are A and X (so server-nodes are {B, C, D} for C1 and {Y, Z, V} for C2).
If client-node A from C1 puts data, the TopologyAwareConsistentHash forces it to put into some node in C2 - this node can be another client-node - X. In this case I'll end with data distributed over 2 nodes which are client-nodes and will not be persisted.
Is the above scenario correct or it is not? If so, how can I protect myself for such situation? Should I deliver my own Hash implementation that extends the TopologyAwareConsistentHash, so it will distinguish the server and client nodes and store data only on server- ones? Is it even achievable?
Putting fixed number of numOwners is not a solution in my case as the client-node can dynamically connect and disconnect from the clusters, so even a high value of numOwners is vulnerable as I don't have control over how many clients will connect.
Thanks in advance for any suggestions!
Cheers!