In-Memory Data Grid - achieve unparalleled speed, persistence, and accuracy.Multi-Site LAN Replication
Multiple Space
Where GigaSpaces data is stored. It is the logical cache that holds data objects in memory and might also hold them in layered in tiering. Data is hosted from multiple SoRs, consolidated as a unified data model. replication is the ability to replicate state between different deployed Spaces (different cluster of Space instances), where each of the Space instances of each of the Spaces are reachable via network to the other. In some cases, this may even be across WAN using VPN or other mechanism to establish a VLAN. However, you must have a direct network connection between all the Space instances of all of the clusters (or at least a connection between all Space instances to the targeted Space WAN Gateway machine). Replicating between Spaces in the same network is done using exactly the same mechanisms and WAN Gateway described in Multi-Site Replication over the WAN. However, the method is simplified because much of the configuration and some of the components are not needed, as the Spaces reside in the same network.
WAN Gateway Features
The GigaSpaces WAN Gateway features the following:
-
Total data consistency, ordering with no data loss - Due to its architecture, the WAN Gateway is stateless and data loss does not happen. Transactions in a source Space are replicated in atomic manner and in the correct order to the remote Spaces.
-
Conflict resolution support - GigaSpaces can identify data conflicts and allow you to decide to override the local copy with the remote replicated copy, reject the remote replicated copy, or merge the local and the remote copy.
-
Monitoring and Management - The WAN Gateway exposes statistics on replication activity to remote Spaces.
-
Multi-Master / Master-Slave support - The WAN Gateway supports all popular replication topologies.
-
Space bootstrapping - After a Space starts, it can reload all its data or just specific data from a different Space without introducing data consistency problems. This functionality can also be used for hot upgrading purposes when a newer version of the application is started and the initial state is bootstrapped from an existing cluster.
-
Data filtering - The WAN Gateway replication can have a custom plug-in that allows users to filter/modify data before and after it is replicated at each source/target Space.
-
Changing replication topology in runtime - Remote Spaces can be added or removed without requiring system shutdown.
If each Space resides on a different network and there is no network connectivity between all the Space instances of all the Spaces, read Multi-Site Replication over the WAN to understand how to establish replication between different networks.
Supported Topologies
This page provides two sample multi-space replication topologies. These are not the only supported topologies. In fact, the permutations of topologies are quite extensive, and we've chosen to demonstrate two of the more common topologies which can also serve as a basis for other topologies as required by the user:
- Multi-master with two spaces, where each space is active and updates its subset of the data.
- Master-slave, where only one space actually updates the data while the rest REpresentational State Transfer. Application Programming Interface
An API, or application programming interface, is a set of rules that define how applications or devices can connect to and communicate with each other. A REST API is an API that conforms to the design principles of the REST, or representational state transfer architectural style. either serve as a backup or use it in read only mode.
For both of the above topologies, replication is done in a similar way: Each space is replicating the relevant data to its target space(s) via the target space WAN Gateway which routes the data to the target space. The data is being replicated asynchronously in a reliable mode, which means that even if a primary space instance fails on the source space, the backup space instance which replaces it will immediately take control and replicate the missing data along with new data that has been generated on the newly elected primary space instance. This is very similar to the Mirror Service replication scheme. The WAN Gateway is discussed in full below.
Replication may use Hub & Spoke, Ring, Hierarchical or Pass-Through architecture:
Configuring a Space With WAN Gateway Targets
A replication from one space to the another is basically a replication from a space to a target WAN Gateway. The source space is decoupled from the target space. Instead, it is configured to replicate to target space's WAN Gateway, the WAN Gateway is in charge of dispatching the incoming replication packets to the relevant target space. Each space needs to be made aware of the target WAN Gateways to which it replicates the data, by specifying the target WAN Gateways in the source space configuration.
From the space's perspective, a replication from one space to a target WAN Gateway is like any other replication channel (e.g mirror, backup...) and the backlog and confirmation state of the replication channel to the target WAN Gateway is kept in the source space. As a result, the WAN Gateway is stateless as far as holding the replication state is concerned, and only the source space is in charge of the replication progress and state. Each WAN Gateway has a unique logical name, in our cases will demonstrate with city names assuming there is a VPN or LAN between the spaces (e.g. "London" or "New York"). This name is used by remote spaces that are replicating to this space via its WAN Gateway.
The following snippet shows how to configure a space that resides in New York to replicate to two other spaces, one in London and one in Hong Kong:
<os-core:embedded-space id="space" space-name="myNYSpace" gateway-targets="gatewayTargets"/>
<os-gateway:targets id="gatewayTargets" local-gateway-name="NEWYORK">
<os-gateway:target name="LONDON"/>
<os-gateway:target name="HONGKONG"/>
</os-gateway:targets>
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="GigaSpaces.XAP GigaSpaces eXtreme Application Platform.
Provides a powerful solution for data processing, launching, and running digital services" type="GigaSpaces.XAP.Configuration.GigaSpacesXAPConfiguration, GigaSpaces.Core"/>
</configSections>
<GigaSpaces.XAP>
<ProcessingUnitContainer Type=
"GigaSpaces.XAP.ProcessingUnit.Containers.BasicContainer.BasicProcessingUnitContainer, GigaSpaces.Core">
<BasicContainer>
<EmbeddedSpaces>
<add Name="myNYSpace">
<Gateway LocalGatewayName="NEWYORK">
<Targets>
<add Name="LONDON"/>
<add Name="HONGKONG"/>
</Targets>
</Gateway>
</add>
</EmbeddedSpaces>
</BasicContainer>
</ProcessingUnitContainer>
</GigaSpaces.XAP>
</configuration>Each of replication channel to the WAN Gateways can be configured with more parameters, such parameters can applied to all WAN Gateways or specifically per WAN Gateway, for example:
<os-core:embedded-space id="space" space-name="myNYSpace" gateway-targets="gatewayTargets"/>
<os-gateway:targets id="gatewayTargets"
local-gateway-name="NEWYORK" bulk-size="1000"
max-redo-log-capacity="1000000">
<os-gateway:target name="LONDON" />
<os-gateway:target name="HONGKONG" bulk-size="100"/>
</os-gateway:targets>
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="GigaSpaces.XAP" type="GigaSpaces.XAP.Configuration.GigaSpacesXAPConfiguration, GigaSpaces.Core"/>
</configSections>
<GigaSpaces.XAP>
<ProcessingUnitContainer Type=
"GigaSpaces.XAP.ProcessingUnit.Containers.BasicContainer.BasicProcessingUnitContainer, GigaSpaces.Core">
<BasicContainer>
<EmbeddedSpaces>
<add Name="myNYSpace">
<Gateway LocalGatewayName="NEWYORK"
BulkSize="1000"
MaxRedoLogCapacity="1000000">
<Targets>
<add Name="LONDON"/>
<add Name="HONGKONG"
bulk-size="100">
</Targets>
</Gateway>
</add>
</EmbeddedSpaces>
</BasicContainer>
</ProcessingUnitContainer>
</GigaSpaces.XAP>
</configuration>Here we have specified a global bulk size of 1000 but have specifically overridden it in the replication channel to Hong Kong with 100, and have a global maximum redo log capacity for both targets of 1000000.
For more details about all the available configuration elements of the space WAN Gateway targets please refer to the Configuring Targets section.
Use the partitioned cluster schema
You should have the partitioned cluster schema used with the space to enable the replication to the WAN Gateway.
If you are not interested in having backups running but have the replication to the WAN Gateway running, you should have ZERO as the number of backups. See below example of an sla.xml configuration you could use in such a case:
<os-sla:sla cluster-schema="partitioned" number-of-instances="1" number-of-backups="0">
</os-sla:sla>
Note that when there are no backups running any failure of the primary might cause a loss of data.
The number of backups per partition is zero or one.
Configuring and Deploying the WAN Gateway
A WAN Gateway needs to be deployed as a processing unit This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity. per space (though, one WAN Gateway processing unit can be used to replicate into more than one space), and it is composed by the sink component which is in charge of dispatching incoming replication from remote spaces into the targeted space.
WAN Gateway Basic Configuration
For Dot Net (.NET) users, WAN Gateway components are deployed using procedures identical in functionality to the Java deployments.
Following the above example, here we demonstrate how to configure the WAN Gateway processing unit in New York, which needs to send replication to London and Hong Kong and also receive replication from the other spaces.
<os-gateway:sink id="sink"
local-gateway-name="NEWYORK"
local-space-url="jini://*/*/myNYSpace">
<os-gateway:sources>
<os-gateway:source name="LONDON" />
<os-gateway:source name="HONGKONG" />
</os-gateway:sources>
</os-gateway:sink>
WAN Gateway and the Mirror Service
A WAN Gateway and a Mirror Service are two different components which can co-exist together without any effect on each other. A WAN Gateway is just another reliable asynchronous target. Due to this fact, we will not discuss or demonstrate mirror service along side with a WAN Gateway because they do not contradict each other or require any special configuration when used in the same space cluster.
WAN Gateway and Distributed Transactions
By default the WAN Gateway will preserve distributed transactions atomicity (distributed transactions consolidation), this can be disabled by adding the following property to the space configuration:
<os-core:embedded-space id="space" space-name="localSpace" gateway-targets="gatewayTargets">
<os-core:properties>
<props>
<prop key="cluster-config.groups.group.repl-policy.processing-type">
global-order
</prop>
</props>
</os-core:properties>
</os-core:embedded-space>
<ProcessingUnit>
<EmbeddedSpaces>
<add Name="MySpace">
<Gateway LocalGatewayName="NEWYORK"
<Targets>
<add Name="LONDON"/>
<add Name="HONGKONG"
</Targets>
</Gateway>
<Properties>
<add Name="cluster-config.groups.group.repl-policy.processing-type" Value="global-order"/>
</Properties>
</add>
</EmbeddedSpaces>
</ProcessingUnit>
Distributed transaction consolidation is done by waiting for all the transaction participants data before processing is done by the Sink component. In some cases, certain distributed transaction participants' data might be delayed due to network delay or disconnection and therefore may cause delays in replication. In order to prevent this potential delay, it is possible to set a timeout parameter which indicates how much time to wait for distributed transactions participants data before processing the data individually for each participant.
It is possible to specify the behavior when processing is split to individual participants upon consolidation failure (timeout or other reasons), the unconsolidated transaction can be either aborted or committed.
Please note that while waiting for the pieces of a distributed transaction to arrive at the sink, replication isn't waiting but keeping the data flow and preventing from conflicts to happen.
The following example demonstrates how to set the timeout for waiting for distributed transaction data to arrive. It is also possible to set the amount of new operations to perform before processing data individually for each participant
<os-gateway:sink id="sink" local-gateway-name="NEWYORK"
local-space-url="jini://*/*/myNYSpace">
<os-gateway:sources>
<os-gateway:source name="LONDON" />
<os-gateway:source name="HONGKONG" />
</os-gateway:sources>
<os-gateway:tx-support
dist-tx-wait-timeout-millis="10000"
dist-tx-wait-for-opers="20"
dist-tx-consolidation-failure-action="commit"/> <!--or "abort"-->
</os-gateway:sink>
Distributed transaction participants data will be processed individually if 10 seconds have passed and not all of the participants data has arrived or if 20 new operations were executed after the distributed transaction.
| Attribute | Default Value |
|---|---|
| dist-tx-wait-timeout-millis | 60000 milliseconds |
| dist-tx-wait-for-opers | unlimited (-1 = unlimited) |
| dist-tx-consolidation-failure-action | commit |
If you set the cluster-config.groups.group.repl-policy.processing-type property to global-source all reliable asynchronous replication targets for that space will work in non-distributed transaction consolidation mode (For example, a Mirror Performs the replication of changes to the target table or accumulation of source table changes used to replicate changes to the target table at a later time. If you have implemented bidirectional replication in your environment, mirroring can occur to and from both the source and target tables. would be in-non distributed transaction consolidation mode as well.)
Consolidation failure can occur under normal circumstances, if the target WAN Gateway is restarted or crashed during the consolidation process. In a case where the transaction was successfully consolidated and executed on the target cluster but the WAN Gateway was stopped while sending confirmation to the transaction participants in the source space and some of them have received the confirmation while others have not. In such case, the transaction is actually successfully executed in the target space and by default when the consolidation failure event will occur the unconfirmed part will reach the conflict resolution handler which by default will abort it and the state will remain consistent.
Due to the above, setting both dist-tx-wait-timeout-millis and dist-tx-wait-for-opers to unlimited (or very high value) is risky and may cause replication backlog accumulation due to a
packet which is unconsolidated and waits for consolidation which may never occur.
Master-Slave Topology
With this architecture, we have a master-slave topology where all data is being manipulated in one space, and two other spaces are reading the data but not updating it. In other words, the "other spaces" - the slaves - should not replicate data to the other WAN Gateways.
In this case, New York's space will be the active space while London and Hong Kong will be the passive spaces. As explained before, being passive does not necessarily means no work is done in these spaces. However, in terms of replication, these spaces should not replicate to the other spaces and usually should not alter data replicated from other spaces because it may cause conflicts.
Like all GigaSpaces Processing Units, the configuration details of each of the above components is placed in a pu file. Here are the contents of the files for each of the components: This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity..xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-core:embedded-space id="space" space-name="myNYSpace" gateway-targets="gatewayTargets"/>
<os-gateway:targets id="gatewayTargets" local-gateway-name="NEWYORK">
<os-gateway:target name="LONDON"/>
<os-gateway:target name="HONGKONG"/>
</os-gateway:targets>
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-core:embedded-space id="space" space-name="myLondonSpace/">
<!-- No gateway targets needed as this space
is not replicating to any gateway-->
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<!--No delegator needed as this site is not replicating to any gateway-->
<os-gateway:sink id="sink" local-gateway-name="LONDON"
gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myLondonSpace">
<os-gateway:sources>
<os-gateway:source name="NEWYORK" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="LONDON"
host="london-gateway-host-machine" discovery-port="10002"
communication-port="8000" />
</os-gateway:lookups>
<!-- Only the lookup parameters of this site is needed since
the sink will only register itself in the lookup service and no delegator
exists so there is no need to find a remote gateway -->
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-core:embedded-space id="space" space-name="myHKSpace"/>
<!-- No gateway targets needed as this space
is not replicating to any gateway-->
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<!-- No delegator needed as this site is not
replicating to any gateway-->
<os-gateway:sink id="sink" local-gateway-name="HONGKONG"
gateway-lookups="gatewayLookups"
local-space-url="jini://*/*/myHKSpace">
<os-gateway:sources>
<os-gateway:source name="NEWYORK" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="HONGKONG"
host="HK-gateway-host-machine" discovery-port="10003"
communication-port="9000" />
</os-gateway:lookups>
<!-- Only the lookup parameters of this site is
needed since the sink will only register itself in
the lookup service and no delegator
exists so there is no need to find a remote gateway -->
</beans>
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="GigaSpaces.XAP" type="GigaSpaces.XAP.Configuration.GigaSpacesXAPConfiguration, GigaSpaces.Core"/>
</configSections>
<GigaSpaces.XAP>
<ProcessingUnitContainer Type=
"GigaSpaces.XAP.ProcessingUnit.Containers.BasicContainer.BasicProcessingUnitContainer, GigaSpaces.Core">
<BasicContainer>
<EmbeddedSpaces>
<add Name="myNYSpace" >
<Gateway LocalGatewayName="NEWYORK">
<Targets>
<add Name="LONDON"/>
<add Name="HONGKONG">
</Targets>
</Gateway>
</add>
</EmbeddedSpaces>
</BasicContainer>
</ProcessingUnitContainer>
</GigaSpaces.XAP>
</configuration>
<configuration>
<configSections>
<section name="GigaSpaces.XAP" type="GigaSpaces.XAP.Configuration.GigaSpacesXAPConfiguration, GigaSpaces.Core"/>
</configSections>
<GigaSpaces.XAP>
<ProcessingUnitContainer Type=
"GigaSpaces.XAP.ProcessingUnit.Containers.BasicContainer.BasicProcessingUnitContainer, GigaSpaces.Core">
<BasicContainer>
<EmbeddedSpaces>
<add Name="myLondonSpace" >
</add>
</EmbeddedSpaces>
</BasicContainer>
</ProcessingUnitContainer>
</GigaSpaces.XAP>
</configuration>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<!--No delegator needed as this site is not replicating to any gateway-->
<os-gateway:sink id="sink" local-gateway-name="LONDON"
gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myLondonSpace">
<os-gateway:sources>
<os-gateway:source name="NEWYORK" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="LONDON"
host="london-gateway-host-machine" discovery-port="10002"
communication-port="8000" />
</os-gateway:lookups>
<!-- Only the lookup parameters of this site is needed since
the sink will only register itself in the lookup service and no delegator
exists so there is no need to find a remote gateway -->
</beans>
<configuration>
<configSections>
<section name="GigaSpaces.XAP" type="GigaSpaces.XAP.Configuration.GigaSpacesXAPConfiguration, GigaSpaces.Core"/>
</configSections>
<GigaSpaces.XAP>
<ProcessingUnitContainer Type=
"GigaSpaces.XAP.ProcessingUnit.Containers.BasicContainer.BasicProcessingUnitContainer, GigaSpaces.Core">
<BasicContainer>
<EmbeddedSpaces>
<add Name="myHKSpace" >
</add>
</EmbeddedSpaces>
</BasicContainer>
</ProcessingUnitContainer>
</GigaSpaces.XAP>
</configuration>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<!-- No delegator needed as this site is not
replicating to any gateway-->
<os-gateway:sink id="sink" local-gateway-name="HONGKONG"
gateway-lookups="gatewayLookups"
local-space-url="jini://*/*/myHKSpace">
<os-gateway:sources>
<os-gateway:source name="NEWYORK" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="HONGKONG"
host="HK-gateway-host-machine" discovery-port="10003"
communication-port="9000" />
</os-gateway:lookups>
<!-- Only the lookup parameters of this site is
needed since the sink will only register itself in
the lookup service and no delegator
exists so there is no need to find a remote gateway -->
</beans>
Multi-Master Topology
With this architecture, we will have a multi-master topology where data is being generated and manipulated in all spaces.
We will demonstrate this using two spaces but any number of spaces is supported in the same manner. In a master-slave topology, each space should try to modify different subsets of the data as much as possible because many conflicts can occur if multiple spaces are changing the same space entries at the same time. Such conflict can be resolved using a conflict resolver which is discussed fully in Conflict Resolution.
This link refers to multi-site replication, where replication is done indirectly via local WAN Gateway delegator to the target WAN Gateway sink. However the subject in this context is the same for both cases.
With the example below we will have only New York and London as the two active spaces.
Here are the contents of the files for each of the components:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-core:embedded-space id="space" space-name="myNYSpace" gateway-targets="gatewayTargets"/>
<os-gateway:targets id="gatewayTargets" local-gateway-name="NEWYORK">
<os-gateway:target name="LONDON"/>
</os-gateway:targets>
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-gateway:delegator id="delegator"
local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups">
<os-gateway:delegations>
<os-gateway:delegation target="LONDON"/>
</os-gateway:delegations>
</os-gateway:delegator>
<os-gateway:sink id="sink" local-gateway-name="NEWYORK"
gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myNYSpace">
<os-gateway:sources>
<os-gateway:source name="LONDON" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="NEWYORK"
host="ny-gateway-host-machine" discovery-port="10001"
communication-port="7000" />
<os-gateway:lookup gateway-name="LONDON"
host="london-gateway-host-machine" discovery-port="10002"
communication-port="8000" />
</os-gateway:lookups>
<!--The above ports and host names are randomly selected
and have no meaning,
all sites could designate the same ports as well-->
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-core:embedded-space id="space" space-name="myLondonSpace"
gateway-targets="gatewayTargets"/>
<os-gateway:targets id="gatewayTargets" local-gateway-name="LONDON">
<os-gateway:target name="NEWYORK"/>
</os-gateway:targets>
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-gateway:delegator id="delegator" local-gateway-name="LONDON"
gateway-lookups="gatewayLookups">
<os-gateway:delegations>
<os-gateway:delegation target="NEWYORK"/>
</os-gateway:delegations>
</os-gateway:delegator>
<os-gateway:sink id="sink" local-gateway-name="LONDON"
gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myLondonSpace">
<os-gateway:sources>
<os-gateway:source name="NEWYORK" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="NEWYORK"
host="ny-gateway-host-machine" discovery-port="10001"
communication-port="7000" />
<os-gateway:lookup gateway-name="LONDON"
host="london-gateway-host-machine" discovery-port="10002"
communication-port="8000" />
</os-gateway:lookups>
<!--The above ports and host names are randomly selected and have no meaning,
all sites could designate the same ports as well-->
</beans>
In this example, the gateway pu.xml is quite symmetric, the only difference is the local gateway name and the target gateway name. In such cases, it may be more convenient to create a single gateway pu.xml and use place holders to override the relevant properties at deploy time by injecting values for these properties:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<bean id="propertiesConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>
<os-gateway:delegator id="delegator"
local-gateway-name="${localGatewayName}" gateway-lookups="gatewayLookups">
<os-gateway:delegations>
<os-gateway:delegation target="NEWYORK"/>
<os-gateway:delegation target="LONDON"/>
</os-gateway:delegations>
</os-gateway:delegator>
<os-gateway:sink id="sink"
local-gateway-name="${localGatewayName}"
gateway-lookups="gatewayLookups" local-space-url="${localSpaceUrl}">
<os-gateway:sources>
<os-gateway:source name="NEWYORK" />
<os-gateway:source name="LONDON" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="NEWYORK"
host="ny-gateway-host-machine" discovery-port="10001"
communication-port="7000" />
<os-gateway:lookup gateway-name="LONDON"
host="london-gateway-host-machine" discovery-port="10002"
communication-port="8000" />
</os-gateway:lookups>
<!--The above ports and host names are randomly selected and have no meaning,
all sites could designate the same ports as well-->
</beans>
In the above example, we both LONDON and NEWYORK are configured at the sources of the sink and as delegation targets. The delegator and the sink filter a gateway target and source if they match their local name. Using the above technique may simplify scenarios that are symmetric, but it is not recommended when the scenarios are not symmetric as it can be unnecessarily confusing.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="GigaSpaces.XAP" type="GigaSpaces.XAP.Configuration.GigaSpacesXAPConfiguration, GigaSpaces.Core"/>
</configSections>
<GigaSpaces.XAP>
<ProcessingUnitContainer Type=
"GigaSpaces.XAP.ProcessingUnit.Containers.BasicContainer.BasicProcessingUnitContainer, GigaSpaces.Core">
<BasicContainer>
<EmbeddedSpaces>
<add Name="myNYSpace" >
<Gateway LocalGatewayName="NEWYORK">
<Targets>
<add Name="LONDON"/>
</Targets>
</Gateway>
</add>
</EmbeddedSpaces>
</BasicContainer>
</ProcessingUnitContainer>
</GigaSpaces.XAP>
</configuration>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-gateway:delegator id="delegator"
local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups">
<os-gateway:delegations>
<os-gateway:delegation target="LONDON"/>
</os-gateway:delegations>
</os-gateway:delegator>
<os-gateway:sink id="sink" local-gateway-name="NEWYORK"
gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myNYSpace">
<os-gateway:sources>
<os-gateway:source name="LONDON" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="NEWYORK"
host="ny-gateway-host-machine" discovery-port="10001"
communication-port="7000" />
<os-gateway:lookup gateway-name="LONDON"
host="london-gateway-host-machine" discovery-port="10002"
communication-port="8000" />
</os-gateway:lookups>
<!--The above ports and host names are randomly selected
and have no meaning,
all sites could designate the same ports as well-->
</beans>
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="GigaSpaces.XAP" type="GigaSpaces.XAP.Configuration.GigaSpacesXAPConfiguration, GigaSpaces.Core"/>
</configSections>
<GigaSpaces.XAP>
<ProcessingUnitContainer Type=
"GigaSpaces.XAP.ProcessingUnit.Containers.BasicContainer.BasicProcessingUnitContainer, GigaSpaces.Core">
<BasicContainer>
<EmbeddedSpaces>
<add Name="myLondonSpace" >
<Gateway LocalGatewayName="LONDON">
<Targets>
<add Name="NEWYORK"/>
</Targets>
</Gateway>
</add>
</EmbeddedSpaces>
</BasicContainer>
</ProcessingUnitContainer>
</GigaSpaces.XAP>
</configuration>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<os-gateway:delegator id="delegator" local-gateway-name="LONDON"
gateway-lookups="gatewayLookups">
<os-gateway:delegations>
<os-gateway:delegation target="NEWYORK"/>
</os-gateway:delegations>
</os-gateway:delegator>
<os-gateway:sink id="sink" local-gateway-name="LONDON"
gateway-lookups="gatewayLookups" local-space-url="jini://*/*/myLondonSpace">
<os-gateway:sources>
<os-gateway:source name="NEWYORK" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="NEWYORK"
host="ny-gateway-host-machine" discovery-port="10001"
communication-port="7000" />
<os-gateway:lookup gateway-name="LONDON"
host="london-gateway-host-machine" discovery-port="10002"
communication-port="8000" />
</os-gateway:lookups>
<!--The above ports and host names are randomly selected and have no meaning,
all sites could designate the same ports as well-->
</beans>
In this example, the gateway pu.xml is quite symmetric, the only difference is the local gateway name and the target gateway name. In such cases, it may be more convenient to create a single gateway pu.xml and use place holders to override the relevant properties at deploy time by injecting values for these properties:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:os-core="http://www.openspaces.org/schema/core"
xmlns:os-events="http://www.openspaces.org/schema/events"
xmlns:os-remoting="http://www.openspaces.org/schema/remoting"
xmlns:os-sla="http://www.openspaces.org/schema/sla"
xmlns:os-gateway="http://www.openspaces.org/schema/core/gateway"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
http://www.openspaces.org/schema/core http://www.openspaces.org/schema/16.3/core/openspaces-core.xsd
http://www.openspaces.org/schema/events http://www.openspaces.org/schema/16.3/events/openspaces-events.xsd
http://www.openspaces.org/schema/remoting http://www.openspaces.org/schema/16.3/remoting/openspaces-remoting.xsd
http://www.openspaces.org/schema/sla http://www.openspaces.org/schema/16.3/sla/openspaces-sla.xsd
http://www.openspaces.org/schema/core/gateway http://www.openspaces.org/schema/16.3/core/gateway/openspaces-gateway.xsd">
<bean id="propertiesConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/>
<os-gateway:delegator id="delegator"
local-gateway-name="${localGatewayName}" gateway-lookups="gatewayLookups">
<os-gateway:delegations>
<os-gateway:delegation target="NEWYORK"/>
<os-gateway:delegation target="LONDON"/>
</os-gateway:delegations>
</os-gateway:delegator>
<os-gateway:sink id="sink"
local-gateway-name="${localGatewayName}"
gateway-lookups="gatewayLookups" local-space-url="${localSpaceUrl}">
<os-gateway:sources>
<os-gateway:source name="NEWYORK" />
<os-gateway:source name="LONDON" />
</os-gateway:sources>
</os-gateway:sink>
<os-gateway:lookups id="gatewayLookups">
<os-gateway:lookup gateway-name="NEWYORK"
host="ny-gateway-host-machine" discovery-port="10001"
communication-port="7000" />
<os-gateway:lookup gateway-name="LONDON"
host="london-gateway-host-machine" discovery-port="10002"
communication-port="8000" />
</os-gateway:lookups>
<!--The above ports and host names are randomly selected and have no meaning,
all sites could designate the same ports as well-->
</beans>
In the above example, we both LONDON and NEWYORK are configured at the sources of the sink and as delegation targets. The delegator and the sink filter a gateway target and source if they match their local name. Using the above technique may simplify scenarios that are symmetric, but it is not recommended when the scenarios are not symmetric as it can be unnecessarily confusing.
Filtering Replication Between WAN Gateways
In some cases, there can be data that should not be replicated between the spaces but should still be replicated locally to the backup or a mirror service. Hence, specifying the object is not replicated does not fit. Since a replication channel to a WAN Gateway is like any other replication channel, a custom Replication Filter at the source space can be used to filter the relevant data from being sent to the target WAN Gateway. This filtering should be based on the replication target name in order to identify that the replication filter is called for the correct outgoing replication to the WAN Gateway.
For full details and example please refer to Filtering Data. This link refers to multi-site replication, where replication is done indirectly via local WAN Gateway delegator to the target WAN Gateway sink. However the subject in this context is the same for both cases.
Bootstrap One Space from Another Space
Bootstrapping a space from another space is a process in which one space is starting fresh and it is being populated with the data of another space. This can be useful after a very long disconnection where the replication redo-log in the source spaces that replicates to this space was dropped due to breaching capacity limitations, and the disconnected space should start fresh. Other reasons may be an explicit planned downtime due-to some maintenance of one space which lead to a complete system bootstrap once restarted. Or bootstrapping a new version of an application where a WAN Gateway target is added dynamically to an existing space, and the new space will bootstrap from the existing one and once finished traffic is diverted to the new space.
For full details of how to enable the bootstrap mechanism refer to Bootstrapping Process.
Changing Replication Topology During Runtime
The topology might change during runtime, for instance a new space can be added and the existing spaces should be familiar with it and start replicating to it and receive replication from it. On the other hand a space can be removed and the existing should stop holding replication backlog for it and drop it from their list of WAN Gateway targets.
For full details of how to add and remove WAN Gateway targets during runtime refer to Changing Deployment during Runtime. This link refers to multi-site replication, where replication is done indirectly via local WAN Gateway delegator to the target WAN Gateway sink. However the subject in this context is the same for both cases.