In-Memory Data Grid - achieve unparalleled speed, persistence, and accuracy.Multi-Region Replication for Disaster Recovery
Multiple site replication is a very common deployment topology in the following scenarios:
- Disaster recovery planning - In such cases, each deployment site is located far from the other sites (for example, on a different continent) so that if one site is completely destroyed or decommissioned, other sites are not affected and can continue to operate normally.
- Failover - When one site acts as a failover over target for another.
- Maintaining data locality - Per site for performance and latency reasons. For example, a global trading application that operates in multiple stock exchanges across the globe needs fast access to Global Reference Data, or an application that's deployed on multiple data centers in the cloud with a need to access the User Profile Data very quickly.
WAN Gateway Features
The GigaSpaces WAN Gateway features the following:
- Optimized bandwidth and WAN connection usage - With the GigaSpaces WAN Gateway, every site uses one connection when interacting with remote sites.
- Total data consistency, ordering with no data lost - Due to its unique architecture where the WAN Gateway is totally stateless, no data loss happens. Transactions at the local site are replicated atomically in the correct order to the remote sites.
- 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 every activity going through the replication to remote sites.
- Indirect replication - The WAN Gateway can replicate a packet from point A to point B via point C, to avoid connectivity problems between points A and B.
- Multi-Master / Master-Slave support - The WAN Gateway supports all popular replication typologies.
- Site bootstrapping - After a site starts, it can reload its entire data or specific data from a remote site without introducing data consistency problems.
- Data filtering - The WAN Gateway replication can have a custom plug-in that allows users to filter/modify data before and after it has been replicated, at each source/target node.
- Changing WAN replication topology during runtime - adding or removing remote sites without system shutdown.
This page describes how to establish replication between multiple Spaces in a typical WAN environment. Each 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. is a separate network and there is a need for a designated outbound and inbound WAN Gateway machine or machines on each network, in order to interact with the other network(s).
Supported Topologies
This page describes two sample multi-site replication topologies. These are not the only supported topologies. In fact, the permutations of topologies are quite extensive, and discuss 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 sites, where each site is active and updates its subset of the data.
- Master-slave, where only one site 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 in a similar way. Each Space replicates the relevant data to its target Space(s) via a local WAN Gateway, which routes the data to the WAN Gateway of the target Space(s) and from there to the target Space. The data is replicated asynchronously in a reliable mode, which means that even if a primary Space instance fails on the source site, the backup Space instance that 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 can use Hub & Spoke, Ring, Hierarchical or Pass-Through architecture:
Configuring a Space With WAN Gateway Targets
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 replication channel to the WAN Gateways can be configured with more parameters, and these 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 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, refer to Configuring Targets.
Use the partitioned cluster schema
You should have the partitioned cluster schema used with the Space to enable 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 the following example of an sla.xml configuration you can use in such a case:
<os-sla:sla cluster-schema="partitioned" number-of-instances="1" number-of-backups="0">
</os-sla:sla>
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 locally 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. in each site, and is composed of two different components; the delegator and the sink. The delegator is in charge of delegating outgoing replication from the local site to a remote WAN Gateway, and the sink is in charge of dispatching incoming replication from remote sites into the local Space.
WAN Gateway Lookup
The different WAN Gateway components need to locate each other across the different sites. For example, a delegator needs to locate the sink of the target WAN Gateway to which it delegates the replication. This lookup is accomplished via dedicated lookup services that the WAN Gateways use to register and locate each other. This lookup process is usually done across the WAN, so the most reasonable way of locating the lookup services is using unicast (multicast is also supported). The following example demonstrates a unicast lookup discovery.
WAN Gateway Basic Configuration
The following is an excerpt from the pu-xml.jar file. For Dot Net developers, note that this deployment is performed using the standard Java deployment process.
Following the above example, here we demonstrate how to configure the local WAN Gateway processing unit in New York, which needs to send replication to London and Hong Kong and also receive replication from these two sites.
<os-gateway:delegator id="delegator"
local-gateway-name="NEWYORK" gateway-lookups="gatewayLookups">
<os-gateway:delegations>
<os-gateway:delegation target="LONDON"/>
<os-gateway:delegation target="HONGKONG"/>
</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:source name="HONGKONG" />
</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:lookup gateway-name="HONGKONG"
host="hk-gateway-host-machine" discovery-port="10003"
communication-port="9000" />
</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-->
In the above example, we see that both the sink and the delegator need a reference to the WAN Gateway lookup configuration, because both components are using this configuration to locate the relevant component or to register themselves. They use their local WAN Gateway name to identify themselves to the lookup configuration, where they should be registered and where they should look for their targets.
The delegator and sink components are actually isolated and can even be deployed in separate Processing Units, but the most simple deployment is to bundle them two together. However, in some cases you may want to separate them across two or more machines due to system load or other reasons.
For full details and available configurations, refer to WAN Gateway Components.
WAN Gateway and the Mirror Service
A WAN Gateway and a Mirror Service are two different components, which can co-exist together without affecting each other. A WAN Gateway is just another reliable asynchronous target. As such, there is no need to demonstrate the mirror service alongside a WAN Gateway because they don't conflict with each other or require any special configuration when used in the same Space cluster.
WAN Gateway and Distributed Transactions
By default, the WAN Gateway preserves the atomicity of distributed transactions (distributed transaction 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 data from all the transaction participants before processing is done by the sink component. In some cases, the data from certain distributed transaction participants may be delayed due to network delay or disconnection, and this can cause delays in replication. In order to prevent this potential delay, you can set a timeout parameter that indicates how much time to wait for distributed transaction participant data before processing the data individually for each participant.
You can specify the behavior when processing is split into individual participants upon consolidation failure (timeout or other reasons); the unconsolidated transaction can be either aborted or committed.
While waiting for the pieces of a distributed transaction to arrive at the sink, replication isn't waiting but is keeping the data flow and preventing conflicts from happening.
The following example shows how to set the timeout for waiting for distributed transaction data to arrive. You can also set the amount of new operations to perform before processing data individually for each participant.
<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: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 participant data will be processed individually if 10 seconds have passed and not all of the participant 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. will also work in non-distributed transaction consolidation mode.
Consolidation failure can occur under normal circumstances, if the target WAN Gateway is restarted or crashes during the consolidation process. For example, you may have a scenario 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 site and some of them received the confirmation while others did not. In this case, the transaction is actually successfully executed in the target site, and by default when the consolidation failure event occurs, the unconfirmed part reaches the conflict resolution handler will abort it (by default), and the state will remain consistent.
Setting both dist-tx-wait-timeout-millis and dist-tx-wait-for-opers to unlimited (or to very high value) is risky. The replication backlog may accumulate due to a packet that is unconsolidated, causing the replication process to wait for consolidation that may never occur.
Master-Slave Topology
With this architecture, we have a master-slave topology where all data is manipulated in one site, and two other sites read the data but don't update it. In other words, the "other sites" - the slaves - should not replicate data to the other WAN Gateways.
In this case, New York's site will be the active site while London and Hong Kong will be the passive sites. As explained before, being passive does not necessarily mean no work is done in these sites. However, in terms of replication over the WAN, these sites should not replicate to the other sites and usually should not alter data replicated from other sites, 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. These are the contents of the file for each component: 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: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:delegation target="HONGKONG"/>
</os-gateway:delegations>
</os-gateway:delegator>
<!--No sink needed as this site is not receiving replication from any gateway-->
<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:lookup gateway-name="HONGKONG" host="hk-gateway-host-machine"
discovery-port="10003" communication-port="9000" />
</os-gateway:lookups>
<!-- The above ports and host names are randomly selected and has 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/">
<!-- 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>
<?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:delegation target="HONGKONG"/>
</os-gateway:delegations>
</os-gateway:delegator>
<!--No sink needed as this site is not receiving replication from any gateway-->
<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:lookup gateway-name="HONGKONG" host="hk-gateway-host-machine"
discovery-port="10003" communication-port="9000" />
</os-gateway:lookups>
<!-- The above ports and host names are randomly selected and has no meaning,
all sites could designate the same ports as well-->
</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="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 have a multi-master topology where data is generated and manipulated in all sites.
The example below describes two sites, but any number of sites is supported in the same manner. In a master-slave topology, each site should try to modify different subsets of the data as much as possible, because many conflicts can occur if multiple sites change the same Space entries at the same time. These conflicts can be resolved using a conflict resolver, which is described in detail in the Multi-Site Conflict Resolution topic.
In the example below, New York and London are the two active sites.
Here are the contents of the file for each component:
<?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.
The Multi-Master running example page in the Service & Best Practices section includes a three-way setup that replicates data between three sites.
Filtering Replication Between WAN Gateways
On occasion, there may be data that should not be replicated between sites but should still be replicated locally to the backup or a mirror service. If this is the case, it isn't suitable to specify that the object should not be replicated. A replication channel to a WAN Gateway is like any other replication channel, so 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 an example, refer to Filtering Data.
Bootstrapping a Site From Another Site
To bootstrap a site from another site is to restart a site Space from scratch, and to populate it with data from another site Space. This can be useful after a very long disconnection where the replication redo-log in the source Spaces that replicate to this site was dropped due to breaching capacity limitations, and the disconnected site should therefore start fresh. Other reasons include an explicit planned downtime due to site maintenance that leads to a complete system bootstrap upon restart.
For more informaion on how to enable the bootstrap mechanism, refer to Bootstrapping Process.
Changing the Site Topology During Runtime
You may have to modify your site topology during runtime. For example, a new site may be added and the existing sites may have to start replicating to it and receive replication from it. Alternatively, a site may be removed and the existing sites should stop holding replication backlogs for the removed site, and delete it from their list of WAN Gateway targets.
For more information on how to add and remove sites during runtime, refer to Changing Deployment during Runtime.
Additional Resources
The following pages in the Services & Best Practices section provide more details on the Multi-Site Replication module:
- Replication Throughput Capacity
- WAN Gateway Replication Benchmark
You can also view the following video: