ReplicatedHashMap of JGroups provides a distributed ConcurrentHashMap implementation. In its simplest form, it propagates every local change to all other instances in the cluster and you get your replicated-HashMap between available cluster members.
In a cluster environment, new node arrivals are highly anticipated, but ReplicatedHashMap doesn’t really keep up with the late joiners. See below execution flow for a late joiner scenario.
| Time | Node A | Node B |
|---|---|---|
| 1 | join | |
| 2 | send 1 | |
| 3 | recv 1 | |
| 4 | observe {1} | |
| 5 | join | |
| 6 | observe {} | |
| 7 | send 2 | |
| 8 | recv 2 | recv 2 |
| 9 | observe {1,2} | observe {2} |
In the above figure, nodes are out of sync at time steps 6 and 9. To avoid such cases, we need to force ReplicatedHashMap for a sync during initialization. For this purpose, quoting with Bela Ban’s (author of JGroups) words,
JChannel.connect() after the creation of ReplicatedHashMap,ReplicatedHashmap.start(), or else there won’t be any state transfer.See ReplicatedHashMap Updates for Late Joiners post in the mailing-list for the related discussion.