A newer version of IMDG is available.

View latest

Want to try Hazelcast Platform?

We’ve combined the in-memory storage of IMDG with the stream processing power of Jet to bring you the all new Hazelcast Platform.

Configuring for IMap and ICache

4.2 4.1 4.0 3.12 3.11 3.10 3.9 3.8 3.7 3.6 3.5

As mentioned before, for now Hazelcast’s map (IMap) and cache (ICache) data structures support WAN Replication. After you define and configure the WAN Replication as explained in previous sections above, you need to bind it to your maps and/or caches.

To enable WAN replication for an IMap or ICache instance, you can use the wan-replication-ref configuration element. Each instance can have a different WAN replication configuration.

Enabling WAN Replication for IMap:

Imagine you have different distributed maps, however only one of those maps should be replicated to a target cluster. To achieve this, configure the map that you want to be replicated by adding the wan-replication-ref element in the map configuration as shown below.

  • XML

  • YAML

<hazelcast>
    ...
    <wan-replication name="london-wan-rep">
        ...
    </wan-replication>
    <map name="my-shared-map">
        <wan-replication-ref name="london-wan-rep">
            <merge-policy>PassThroughMergePolicy</merge-policy>
            <republishing-enabled>false</republishing-enabled>
        </wan-replication-ref>
    </map>
    ...
</hazelcast>
hazelcast:
  wan-replication:
    london-wan-rep:
      ...
  map:
    my-shared-map:
      wan-replication-ref:
        london-wan-rep:
          merge-policy: PassThroughMergePolicy
          republishing-enabled: false

The following is the equivalent programmatic configuration:

        Config config = new Config();

        WanReplicationConfig wrConfig = new WanReplicationConfig();
        wrConfig.setName("my-wan-cluster");

        config.addWanReplicationConfig(wrConfig);

        WanReplicationRef wanRef = new WanReplicationRef();
        wanRef.setName("my-wan-cluster");
        wanRef.setMergePolicyClassName(PassThroughMergePolicy.class.getName());
        wanRef.setRepublishingEnabled(false);
        config.getMapConfig("my-shared-map").setWanReplicationRef(wanRef);

You see that we have my-shared-map configured to replicate itself to the cluster targets defined in the earlier wan-replication element.

wan-replication-ref has the following elements;

  • name: Name of the wan-replication configuration. IMap or ICache instance uses this wan-replication configuration.

  • merge-policy: Policy to resolve conflicts that occur when the target cluster already has the replicated entry key. This configuration element is optional. If it is not specified, com.hazelcast.spi.merge.PassThroughMergePolicy will be used as the merge policy.

  • republishing-enabled: When enabled, an incoming event to a member is forwarded to target cluster of that member. Enabling the event republishing is useful in a scenario where cluster A replicates to cluster B and cluster B replicates to cluster C. You do not need to enable republishing when all your clusters replicate to each other.

When using Active-Active Replication, multiple clusters can simultaneously update the same entry in a distributed data structure. You can configure a merge policy to resolve these potential conflicts, as shown in the above example configuration (using the merge-policy sub-element under the wan-replication-ref element).

Hazelcast provides the following merge policies for IMap:

  • PutIfAbsentMergePolicy: Incoming entry merges from the source map to the target map if it does not exist in the target map.

  • HigherHitsMergePolicy: Incoming entry merges from the source map to the target map if the source entry has more hits than the target one.

  • PassThroughMergePolicy: Incoming entry merges from the source map to the target map unless the incoming entry is not null.

  • ExpirationTimeMergePolicy: Incoming entry merges from the source map to the target map if the source entry will expire later than the destination entry. Please note that this merge policy can only be used when the clusters' clocks are in sync.

  • LatestAccessMergePolicy: Incoming entry merges from the source map to the target map if the source entry has been accessed more recently than the destination entry. Please note that this merge policy can only be used when the clusters' clocks are in sync.

  • LatestUpdateMergePolicy: Incoming entry merges from the source map to the target map if the source entry has been updated more recently than the target entry. Please note that this merge policy can only be used when the clusters' clocks are in sync.

When using WAN replication, please note that the key based operations are replicated to the target cluster, except evict(). Also the results of entry processors are also replicated.
Note that WAN replication does not replicate configurations, but only the events, i.e., data inserts, updates and removals. When a map or cache is replicated and the target cluster does not have a configuration for that map or cache, the default configuration will apply on the target cluster.

Enabling WAN Replication for ICache:

The following is a declarative configuration example for enabling WAN Replication for ICache:

  • XML

  • YAML

<hazelcast>
    ...
    <wan-replication name="london-wan-rep">
        ...
    </wan-replication>
    <cache name="my-shared-cache">
        <wan-replication-ref name="london-wan-rep">
            <merge-policy>PassThroughMergePolicy</merge-policy>
            <republishing-enabled>true</republishing-enabled>
        </wan-replication-ref>
    </cache>
    ...
</hazelcast>
hazelcast:
  wan-replication:
    london-wan-rep:
      ...
  cache:
    my-shared-cache:
      wan-replication-ref:
        london-wan-rep:
          merge-policy: PassThroughMergePolicy
          republishing-enabled: true

The following is the equivalent programmatic configuration:

        Config config = new Config();

        WanReplicationConfig wrConfig = new WanReplicationConfig();
        wrConfig.setName("my-wan-cluster");

        config.addWanReplicationConfig(wrConfig);

        WanReplicationRef cacheWanRef = new WanReplicationRef();
        cacheWanRef.setName("my-wan-cluster");
        cacheWanRef.setMergePolicyClassName("com.hazelcast.spi.merge.PassThroughMergePolicy");
        cacheWanRef.setRepublishingEnabled(true);
        config.getCacheConfig("my-shared-cache").setWanReplicationRef(cacheWanRef);
Caches that are created dynamically do not support WAN replication functionality. Cache configurations should be defined either declaratively (by XML/YAML) or programmatically on both source and target clusters.

Hazelcast provides the following merge policies for ICache:

  • PutIfAbsentMergePolicy: Incoming entry merges from the source cache to the target cache if it does not exist in the target cache.

  • HigherHitsMergePolicy: Incoming entry merges from the source cache to the target cache if the source entry has more hits than the target one.

  • PassThroughMergePolicy: Incoming entry merges from the source cache to the target cache unless the incoming entry is not null.

  • ExpirationTimeMergePolicy: Incoming entry merges from the source cache to the target cache if the source entry will expire later than the destination entry. Please note that this merge policy can only be used when the clusters' clocks are in sync.

  • LatestAccessMergePolicy: Incoming entry merges from the source cache to the target cache if the source entry has been accessed more recently than the destination entry. Please note that this merge policy can only be used when the clusters' clocks are in sync.

  • LatestUpdateMergePolicy: Incoming entry merges from the source cache to the target cache if the source entry has been updated more recently than the target entry. Please note that this merge policy can only be used when the clusters' clocks are in sync.

lifebuoy

Help and support