You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@geode.apache.org by ud...@apache.org on 2017/08/23 20:55:13 UTC
[09/25] geode git commit: GEODE-3395 Variable-ize product version and
name in user guide - Topo & Comms
GEODE-3395 Variable-ize product version and name in user guide - Topo & Comms
Project: http://git-wip-us.apache.org/repos/asf/geode/repo
Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/e2c3d531
Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/e2c3d531
Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/e2c3d531
Branch: refs/heads/feature/GEODE-3503
Commit: e2c3d531f6bf7aeddb0ce38ab356ec415e32fb48
Parents: b77e1c7
Author: Dave Barnes <db...@pivotal.io>
Authored: Tue Aug 22 14:08:59 2017 -0700
Committer: Dave Barnes <db...@pivotal.io>
Committed: Tue Aug 22 14:08:59 2017 -0700
----------------------------------------------------------------------
.../topologies_and_comm/book_intro.html.md.erb | 12 ++++-----
.../chapter_overview.html.md.erb | 18 +++++++-------
...nt_server_example_configurations.html.md.erb | 2 +-
.../client_server_whats_next.html.md.erb | 2 +-
.../chapter_overview.html.md.erb | 10 ++++----
.../multisite_topologies.html.md.erb | 4 +--
.../setting_up_a_multisite_system.html.md.erb | 22 ++++++++---------
.../chapter_overview.html.md.erb | 8 +++---
.../setting_up_peer_communication.html.md.erb | 4 +--
.../topology_concepts/IPv4_and_IPv6.html.md.erb | 6 ++---
.../chapter_overview.html.md.erb | 26 ++++++++++----------
.../how_communication_works.html.md.erb | 16 ++++++------
.../how_member_discovery_works.html.md.erb | 10 ++++----
.../how_multisite_systems_work.html.md.erb | 20 +++++++--------
.../how_server_discovery_works.html.md.erb | 4 +--
...how_the_pool_manages_connections.html.md.erb | 2 +-
.../member_communication.html.md.erb | 2 +-
.../topology_types.html.md.erb | 10 ++++----
.../using_bind_addresses.html.md.erb | 12 ++++-----
19 files changed, 95 insertions(+), 95 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/book_intro.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/book_intro.html.md.erb b/geode-docs/topologies_and_comm/book_intro.html.md.erb
index f7de5ed..daf705a 100644
--- a/geode-docs/topologies_and_comm/book_intro.html.md.erb
+++ b/geode-docs/topologies_and_comm/book_intro.html.md.erb
@@ -19,23 +19,23 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-*Topologies and Communication* explains how to plan and configure Apache Geode member discovery, peer-to-peer and client/server communication topologies.
+*Topologies and Communication* explains how to plan and configure <%=vars.product_name_long%> member discovery, peer-to-peer and client/server communication topologies.
<a id="concept_7628F498DB534A2D8A99748F5DA5DC94__section_E62DEF9610814012A3307D50A56FE1B4"></a>
-- **[Topology and Communication General Concepts](../topologies_and_comm/topology_concepts/chapter_overview.html)**
+- **[Topology and Communication General Concepts](topology_concepts/chapter_overview.html)**
- Before you configure your Apache Geode members, make sure you understand the options for topology and communication.
+ Before you configure your <%=vars.product_name_long%> members, make sure you understand the options for topology and communication.
-- **[Peer-to-Peer Configuration](../topologies_and_comm/p2p_configuration/chapter_overview.html)**
+- **[Peer-to-Peer Configuration](p2p_configuration/chapter_overview.html)**
Use peer-to-peer configuration to set member discovery and communication within a single distributed system.
-- **[Client/Server Configuration](../topologies_and_comm/cs_configuration/chapter_overview.html)**
+- **[Client/Server Configuration](cs_configuration/chapter_overview.html)**
In the client/server architecture, a relatively small server farm manages the cached data of and access to the same data for many client applications. Clients can update and access data efficiently, leaving the servers to manage data distribution to other clients and any synchronization with outside data stores.
-- **[Multi-site (WAN) Configuration](../topologies_and_comm/multi_site_configuration/chapter_overview.html)**
+- **[Multi-site (WAN) Configuration](multi_site_configuration/chapter_overview.html)**
Use the multi-site configuration to scale horizontally between disparate, loosely-coupled distributed systems. A wide-area network (WAN) is the main use case for the multi-site topology.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/cs_configuration/chapter_overview.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/cs_configuration/chapter_overview.html.md.erb b/geode-docs/topologies_and_comm/cs_configuration/chapter_overview.html.md.erb
index 45a8855..76d4aae 100644
--- a/geode-docs/topologies_and_comm/cs_configuration/chapter_overview.html.md.erb
+++ b/geode-docs/topologies_and_comm/cs_configuration/chapter_overview.html.md.erb
@@ -21,31 +21,31 @@ limitations under the License.
In the client/server architecture, a relatively small server farm manages the cached data of and access to the same data for many client applications. Clients can update and access data efficiently, leaving the servers to manage data distribution to other clients and any synchronization with outside data stores.
-- **[Standard Client/Server Deployment](../../topologies_and_comm/cs_configuration/standard_client_server_deployment.html)**
+- **[Standard Client/Server Deployment](standard_client_server_deployment.html)**
In the most common client/server topology, a farm of cache servers provides caching services to many clients. Cache servers have a homogeneous data store in data regions that are replicated or partitioned across the server farm.
-- **[How Server Discovery Works](../../topologies_and_comm/topology_concepts/how_server_discovery_works.html)**
+- **[How Server Discovery Works](../topology_concepts/how_server_discovery_works.html)**
- Apache Geode locators provide reliable and flexible server discovery services for your clients. You can use all servers for all client requests, or group servers according to function, with the locators directing each client request to the right group of servers.
+ <%=vars.product_name_long%> locators provide reliable and flexible server discovery services for your clients. You can use all servers for all client requests, or group servers according to function, with the locators directing each client request to the right group of servers.
-- **[How Client/Server Connections Work](../../topologies_and_comm/topology_concepts/how_the_pool_manages_connections.html)**
+- **[How Client/Server Connections Work](../topology_concepts/how_the_pool_manages_connections.html)**
- The server pools in your Apache Geode client processes manage all client connection requests to the server tier. To make the best use of the pool functionality, you should understand how the pool manages the server connections.
+ The server pools in your <%=vars.product_name_long%> client processes manage all client connection requests to the server tier. To make the best use of the pool functionality, you should understand how the pool manages the server connections.
-- **[Configuring a Client/Server System](../../topologies_and_comm/cs_configuration/setting_up_a_client_server_system.html)**
+- **[Configuring a Client/Server System](setting_up_a_client_server_system.html)**
Configure your server and client processes and data regions to run your client/server system.
-- **[Organizing Servers Into Logical Member Groups](../../topologies_and_comm/cs_configuration/configure_servers_into_logical_groups.html)**
+- **[Organizing Servers Into Logical Member Groups](configure_servers_into_logical_groups.html)**
In a client/server configuration, by putting servers into logical member groups, you can control which servers your clients use and target specific servers for specific data or tasks. You can configure servers to manage different data sets or to direct specific client traffic to a subset of servers, such as those directly connected to a back-end database.
-- **[Client/Server Example Configurations](../../topologies_and_comm/cs_configuration/client_server_example_configurations.html)**
+- **[Client/Server Example Configurations](client_server_example_configurations.html)**
For easy configuration, you can start with these example client/server configurations and modify for your systems.
-- **[Fine-Tuning Your Client/Server Configuration](../../topologies_and_comm/cs_configuration/client_server_whats_next.html)**
+- **[Fine-Tuning Your Client/Server Configuration](client_server_whats_next.html)**
You can fine-tune your client/server system with server load-balancing and client thread use of pool connections. For example, you can configure how often the servers check their load with the cache server `load-poll-interval` property, or configure your own server load metrics by implementing the `org.apache.geode.cache.server` package.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/cs_configuration/client_server_example_configurations.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/cs_configuration/client_server_example_configurations.html.md.erb b/geode-docs/topologies_and_comm/cs_configuration/client_server_example_configurations.html.md.erb
index eeafbe5..48f6126 100644
--- a/geode-docs/topologies_and_comm/cs_configuration/client_server_example_configurations.html.md.erb
+++ b/geode-docs/topologies_and_comm/cs_configuration/client_server_example_configurations.html.md.erb
@@ -62,7 +62,7 @@ gfsh>start server --name=server1 --server-port=40404
See `start server`.
-The client’s `cache.xml` `<client-cache>` declaration automatically configures it as a standalone Geode application.
+The client’s `cache.xml` `<client-cache>` declaration automatically configures it as a standalone <%=vars.product_name%> application.
The client's `cache.xml`:
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/cs_configuration/client_server_whats_next.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/cs_configuration/client_server_whats_next.html.md.erb b/geode-docs/topologies_and_comm/cs_configuration/client_server_whats_next.html.md.erb
index 6da8f32..4e7c03e 100644
--- a/geode-docs/topologies_and_comm/cs_configuration/client_server_whats_next.html.md.erb
+++ b/geode-docs/topologies_and_comm/cs_configuration/client_server_whats_next.html.md.erb
@@ -30,7 +30,7 @@ When the client pool requests connection information from the server locator, th
- Between updates from the servers, the locators estimate which server is the least loaded by using the server estimates for the cost of additional connections. For example, if the current pool connection load for a server’s connections is 0.4 and each additional connection would add 0.1 to its load, the locator can estimate that adding two new pool connections will take the server’s pool connection load to 0.6.
- Locators do not share connection information among themselves. These estimates provide rough guidance to the individual locators for the periods between updates from the servers.
-Geode provides a default utility that probes the server and its resource usage to give load information to the locators. The default probe returns the following load metrics:
+<%=vars.product_name%> provides a default utility that probes the server and its resource usage to give load information to the locators. The default probe returns the following load metrics:
- The pool connection load is the number of connections to the server divided by the server’s `max-connections` setting. This means that servers with a lower `max-connections` setting receives fewer connections than servers with a higher setting. The load is a number between 0 and 1, where 0 means there are no connections, and 1 means the server is at `max-connections`. The load estimate for each additional pool connection is 1/`max-connections`.
- The subscription connection load is the number of subscription queues hosted by this server. The load estimate for each additional subscription connection is 1.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/multi_site_configuration/chapter_overview.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/multi_site_configuration/chapter_overview.html.md.erb b/geode-docs/topologies_and_comm/multi_site_configuration/chapter_overview.html.md.erb
index b5f627b..9d62e26 100644
--- a/geode-docs/topologies_and_comm/multi_site_configuration/chapter_overview.html.md.erb
+++ b/geode-docs/topologies_and_comm/multi_site_configuration/chapter_overview.html.md.erb
@@ -21,21 +21,21 @@ limitations under the License.
Use the multi-site configuration to scale horizontally between disparate, loosely-coupled distributed systems. A wide-area network (WAN) is the main use case for the multi-site topology.
-- **[How Multi-site (WAN) Systems Work](../../topologies_and_comm/topology_concepts/how_multisite_systems_work.html)**
+- **[How Multi-site (WAN) Systems Work](../topology_concepts/how_multisite_systems_work.html)**
- The Apache Geode multi-site implementation connects disparate distributed systems. The systems act as one when they are coupled, and they act as independent systems when communication between sites fails. The coupling is tolerant of weak or slow links between distributed system sites. A wide-area network (WAN) is the main use case for the multi-site topology.
+ The <%=vars.product_name_long%> multi-site implementation connects disparate distributed systems. The systems act as one when they are coupled, and they act as independent systems when communication between sites fails. The coupling is tolerant of weak or slow links between distributed system sites. A wide-area network (WAN) is the main use case for the multi-site topology.
-- **[Multi-site (WAN) Topologies](../../topologies_and_comm/multi_site_configuration/multisite_topologies.html)**
+- **[Multi-site (WAN) Topologies](multisite_topologies.html)**
To configure your multi-site topology, you should understand the recommended topologies and the topologies to avoid.
-- **[Configuring a Multi-site (WAN) System](../../topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html)**
+- **[Configuring a Multi-site (WAN) System](setting_up_a_multisite_system.html)**
Plan and configure your multi-site topology, and configure the regions that will be shared between systems.
- **[Filtering Events for Multi-Site (WAN) Distribution](../../developing/events/filtering_multisite_events.html)**
- You can optionally create gateway sender and/or gateway receiver filters to control which events are queued and distributed to a remote site, or to modify the data stream that is transmitted between Geode sites.
+ You can optionally create gateway sender and/or gateway receiver filters to control which events are queued and distributed to a remote site, or to modify the data stream that is transmitted between <%=vars.product_name%> sites.
- **[Resolving Conflicting Events](../../developing/events/resolving_multisite_conflicts.html)**
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/multi_site_configuration/multisite_topologies.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/multi_site_configuration/multisite_topologies.html.md.erb b/geode-docs/topologies_and_comm/multi_site_configuration/multisite_topologies.html.md.erb
index b710b8d..89f961b 100644
--- a/geode-docs/topologies_and_comm/multi_site_configuration/multisite_topologies.html.md.erb
+++ b/geode-docs/topologies_and_comm/multi_site_configuration/multisite_topologies.html.md.erb
@@ -22,9 +22,9 @@ limitations under the License.
To configure your multi-site topology, you should understand the recommended topologies and the topologies to avoid.
<a id="multisite_topologies__section_26A561471249495A847B4C3854EE04C9"></a>
-This section describes Geode's support for various topologies. Depending on your application needs, there may be several topologies that work. These are considerations to keep in mind:
+This section describes <%=vars.product_name%>'s support for various topologies. Depending on your application needs, there may be several topologies that work. These are considerations to keep in mind:
-- When a Geode site receives a message from a gateway sender, it forwards it to the other sites it knows about, excluding those sites that it knows have already seen the message. Each message contains the initial sender's ID and the ID of each of the sites the initial sender sent to, so no site forwards to those sites. However, messages do not pick up the ID of the sites they pass through, so it is possible in certain topologies for more than one copy of a message to be sent to one site.
+- When a <%=vars.product_name%> site receives a message from a gateway sender, it forwards it to the other sites it knows about, excluding those sites that it knows have already seen the message. Each message contains the initial sender's ID and the ID of each of the sites the initial sender sent to, so no site forwards to those sites. However, messages do not pick up the ID of the sites they pass through, so it is possible in certain topologies for more than one copy of a message to be sent to one site.
- In some configurations, the loss of one site affects how other sites communicate with one another.
## <a id="multisite_topologies__section_7ECE1AFB1F94446FAA0A9FD504217C76" class="no-quick-link"></a>Fully Connected Mesh Topology
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb b/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb
index dd2bc3a..8e03069 100644
--- a/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb
+++ b/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb
@@ -25,7 +25,7 @@ Plan and configure your multi-site topology, and configure the regions that will
Before you start, you should understand how to configure membership and communication in peer-to-peer systems using locators. See [Configuring Peer-to-Peer Discovery](../p2p_configuration/setting_up_a_p2p_system.html) and [Configuring Peer Communication](../p2p_configuration/setting_up_peer_communication.html).
-WAN deployments increase the messaging demands on a Geode system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for Geode members that participate in a WAN deployment. See [Configuring Sockets in Multi-Site (WAN) Deployments](../../managing/monitor_tune/sockets_and_gateways.html) and [Making Sure You Have Enough Sockets](../../managing/monitor_tune/socket_communication_have_enough_sockets.html).
+WAN deployments increase the messaging demands on a <%=vars.product_name%> system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for <%=vars.product_name%> members that participate in a WAN deployment. See [Configuring Sockets in Multi-Site (WAN) Deployments](../../managing/monitor_tune/sockets_and_gateways.html) and [Making Sure You Have Enough Sockets](../../managing/monitor_tune/socket_communication_have_enough_sockets.html).
## <a id="setting_up_a_multisite_system__section_86F9FE9D786D407FB438C56E43FC5DB1" class="no-quick-link"></a>Main Steps
@@ -43,7 +43,7 @@ Use the following steps to configure a multi-site system:
3. Configure the gateway senders that you will use to distribute region events to remote systems. See [Configure Gateway Senders](setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_1500299A8F9A4C2385680E337F5D3DEC).
4. Create the data regions that you want to participate in the multi-site system, specifying the gateway sender(s) that each region should use for WAN distribution. Configure the same regions in the target clusters to apply the distributed events. See [Create Data Regions for Multi-site Communication](setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E1DEDD0743D54831AFFBCCDC750F8879).
-5. Configure gateway receivers in each Geode cluster that will receive region events from another cluster. See [Configure Gateway Receivers](setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B).
+5. Configure gateway receivers in each <%=vars.product_name%> cluster that will receive region events from another cluster. See [Configure Gateway Receivers](setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B).
6. Start distributed system member processes in the correct order (locators first, followed by data nodes) to ensure efficient discovery of WAN resources. See [Starting Up and Shutting Down Your System](../../configuring/running/starting_up_shutting_down.html).
7. (Optional.) Deploy custom conflict resolvers to handle resolve potential conflicts that are detected when applying events from over a WAN. See [Resolving Conflicting Events](../../developing/events/resolving_multisite_conflicts.html#topic_E97BB68748F14987916CD1A50E4B4542).
8. (Optional.) Deploy WAN filters to determine which events are distributed over the WAN, or to modify events as they are distributed over the WAN. See [Filtering Events for Multi-Site (WAN) Distribution](../../developing/events/filtering_multisite_events.html#topic_E97BB68748F14987916CD1A50E4B4542).
@@ -63,11 +63,11 @@ To configure a gateway sender that uses gfsh to create the cache.xml configurati
See [WAN Configuration](../../reference/topics/elements_ref.html#topic_7B1CABCAD056499AA57AF3CFDBF8ABE3) for more information about individual configuration properties.
-1. For each Geode system, choose the members that will host a gateway sender configuration and distribute region events to remote sites:
- - You must deploy a parallel gateway sender configuration on each Geode member that hosts a region that uses the sender.
- - You may choose to deploy a serial gateway sender configuration on one or more Geode members in order to provide high availability. However, only one instance of a given serial gateway sender configuration distributes region events at any given time.
+1. For each <%=vars.product_name%> system, choose the members that will host a gateway sender configuration and distribute region events to remote sites:
+ - You must deploy a parallel gateway sender configuration on each <%=vars.product_name%> member that hosts a region that uses the sender.
+ - You may choose to deploy a serial gateway sender configuration on one or more <%=vars.product_name%> members in order to provide high availability. However, only one instance of a given serial gateway sender configuration distributes region events at any given time.
-2. Configure each gateway sender on a Geode member using gfsh, `cache.xml` or Java API:
+2. Configure each gateway sender on a <%=vars.product_name%> member using gfsh, `cache.xml` or Java API:
- **gfsh configuration command**
``` pre
@@ -77,7 +77,7 @@ See [WAN Configuration](../../reference/topics/elements_ref.html#topic_7B1CABCAD
```
- **cache.xml configuration**
- These example `cache.xml` entries configure two parallel gateway senders to distribute region events to two remote Geode clusters (clusters "2" and "3"):
+ These example `cache.xml` entries configure two parallel gateway senders to distribute region events to two remote <%=vars.product_name%> clusters (clusters "2" and "3"):
``` pre
<cache>
@@ -176,7 +176,7 @@ See [WAN Configuration](../../reference/topics/elements_ref.html#topic_7B1CABCAD
```
**Note:**
-The gateway sender configuration for a specific sender `id` must be identical on each Geode member that hosts the gateway sender.
+The gateway sender configuration for a specific sender `id` must be identical on each <%=vars.product_name%> member that hosts the gateway sender.
## <a id="setting_up_a_multisite_system__section_E1DEDD0743D54831AFFBCCDC750F8879" class="no-quick-link"></a>Create Data Regions for Multi-site Communication
@@ -227,14 +227,14 @@ In addition to configuring regions with gateway senders to distribute events, yo
## <a id="setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B" class="no-quick-link"></a>Configure Gateway Receivers
-Always configure a gateway receiver in each Geode cluster that will receive and apply region events from another cluster.
+Always configure a gateway receiver in each <%=vars.product_name%> cluster that will receive and apply region events from another cluster.
-A gateway receiver configuration can be applied to multiple Geode servers for load balancing and high availability. However, each Geode member that hosts a gateway receiver must also define all of the regions for which the receiver may receive an event. If a gateway receiver receives an event for a region that the local member does not define, Geode throws an exception. See [Create Data Regions for Multi-site Communication](setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E1DEDD0743D54831AFFBCCDC750F8879).
+A gateway receiver configuration can be applied to multiple <%=vars.product_name%> servers for load balancing and high availability. However, each <%=vars.product_name%> member that hosts a gateway receiver must also define all of the regions for which the receiver may receive an event. If a gateway receiver receives an event for a region that the local member does not define, <%=vars.product_name%> throws an exception. See [Create Data Regions for Multi-site Communication](setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E1DEDD0743D54831AFFBCCDC750F8879).
**Note:**
You can only host one gateway receiver per member.
-A gateway receiver configuration specifies a range of possible port numbers on which to listen. The Geode server picks an unused port number from the specified range to use for the receiver process. You can use this functionality to easily deploy the same gateway receiver configuration to multiple members.
+A gateway receiver configuration specifies a range of possible port numbers on which to listen. The <%=vars.product_name%> server picks an unused port number from the specified range to use for the receiver process. You can use this functionality to easily deploy the same gateway receiver configuration to multiple members.
You can optionally configure gateway receivers to provide a specific IP address or host name for gateway sender connections. If you configure hostname-for-senders, locators will use the provided host name or IP address when instructing gateway senders on how to connect to gateway receivers. If you provide "" or null as the value, by default the gateway receiver's bind-address will be sent to clients.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/p2p_configuration/chapter_overview.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/p2p_configuration/chapter_overview.html.md.erb b/geode-docs/topologies_and_comm/p2p_configuration/chapter_overview.html.md.erb
index 22c026f..7a4febc 100644
--- a/geode-docs/topologies_and_comm/p2p_configuration/chapter_overview.html.md.erb
+++ b/geode-docs/topologies_and_comm/p2p_configuration/chapter_overview.html.md.erb
@@ -21,15 +21,15 @@ limitations under the License.
Use peer-to-peer configuration to set member discovery and communication within a single distributed system.
-- **[Configuring Peer-to-Peer Discovery](../../topologies_and_comm/p2p_configuration/setting_up_a_p2p_system.html)**
+- **[Configuring Peer-to-Peer Discovery](setting_up_a_p2p_system.html)**
Peer members discover each other using one or more locators.
-- **[Configuring Peer Communication](../../topologies_and_comm/p2p_configuration/setting_up_peer_communication.html)**
+- **[Configuring Peer Communication](setting_up_peer_communication.html)**
- By default Apache Geode uses TCP for communication between members of a single distributed system. You can modify this at the member and region levels.
+ By default <%=vars.product_name_long%> uses TCP for communication between members of a single distributed system. You can modify this at the member and region levels.
-- **[Organizing Peers into Logical Member Groups](../../topologies_and_comm/p2p_configuration/configuring_peer_member_groups.html)**
+- **[Organizing Peers into Logical Member Groups](configuring_peer_member_groups.html)**
In a peer-to-peer configuration, you can organize members into logical member groups and use those groups to associate specific data or assign tasks to a pre-defined set of members.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/p2p_configuration/setting_up_peer_communication.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/p2p_configuration/setting_up_peer_communication.html.md.erb b/geode-docs/topologies_and_comm/p2p_configuration/setting_up_peer_communication.html.md.erb
index 9598aa6..fdd678a 100644
--- a/geode-docs/topologies_and_comm/p2p_configuration/setting_up_peer_communication.html.md.erb
+++ b/geode-docs/topologies_and_comm/p2p_configuration/setting_up_peer_communication.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-By default Apache Geode uses TCP for communication between members of a single distributed system. You can modify this at the member and region levels.
+By default <%=vars.product_name_long%> uses TCP for communication between members of a single distributed system. You can modify this at the member and region levels.
<a id="setting_up_communication__section_34509F5B17A943D8BBF19A3497E32BAE"></a>
Before you begin, you should have already determined the address and port settings for multicast, including any bind addresses. See [Topology and Communication General Concepts](../topology_concepts/chapter_overview.html).
@@ -57,7 +57,7 @@ See the [Reference](../../reference/book_intro.html#reference).
```
**Note:**
- Improperly configured multicast can affect production systems. If you intend to use multicast on a shared network, work with your network administrator and system administrator from the planning stage of the project. In addition, you may need to address interrelated setup and tuning issues at the Geode, operating system, and network level.
+ Improperly configured multicast can affect production systems. If you intend to use multicast on a shared network, work with your network administrator and system administrator from the planning stage of the project. In addition, you may need to address interrelated setup and tuning issues at the <%=vars.product_name%>, operating system, and network level.
Once your members establish their connections to each other, they will send distributed data and messages according to your configuration.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/IPv4_and_IPv6.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/IPv4_and_IPv6.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/IPv4_and_IPv6.html.md.erb
index 07f0328..7fdc77f 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/IPv4_and_IPv6.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/IPv4_and_IPv6.html.md.erb
@@ -19,13 +19,13 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-By default, Apache Geode uses Internet Protocol version 4 for Geode address specifications. You can switch to Internet Protocol version 6 if all your machines support it. You may lose performance, so you need to understand the costs of making the switch.
+By default, <%=vars.product_name_long%> uses Internet Protocol version 4 for <%=vars.product_name%> address specifications. You can switch to Internet Protocol version 6 if all your machines support it. You may lose performance, so you need to understand the costs of making the switch.
<a id="IPv4_and_IPv6__section_027647C0034042C087FD5C8DBCB8482B"></a>
- IPv4 uses a 32-bit address. IPv4 was the first protocol and is still the main one in use, but its address space is expected to be exhausted within a few years.
- IPv6 uses a 128-bit address. IPv6 succeeds IPv4, and will provide a much greater number of addresses.
-Based on current testing with Geode , IPv4 is generally recommended. IPv6 connections tend to take longer to form and the communication tends to be slower. Not all machines support IPv6 addressing. To use IPv6, all machines in your distributed system must support it or you will have connectivity problems.
+Based on current testing with <%=vars.product_name%> , IPv4 is generally recommended. IPv6 connections tend to take longer to form and the communication tends to be slower. Not all machines support IPv6 addressing. To use IPv6, all machines in your distributed system must support it or you will have connectivity problems.
**Note:**
Do not mix IPv4 and IPv6 addresses. Use one or the other, across the board.
@@ -34,7 +34,7 @@ IPv4 is the default version.
To use IPv6, set the Java property, `java.net.preferIPv6Addresses`, to `true`.
-These examples show the formats to use to specify addresses in Geode .
+These examples show the formats to use to specify addresses in <%=vars.product_name%> .
- IPv4:
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/chapter_overview.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/chapter_overview.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/chapter_overview.html.md.erb
index 95d0a3f..5cbd1a0 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/chapter_overview.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/chapter_overview.html.md.erb
@@ -19,30 +19,30 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Before you configure your Apache Geode members, make sure you understand the options for topology and communication.
+Before you configure your <%=vars.product_name_long%> members, make sure you understand the options for topology and communication.
-- **[Topology Types](../../topologies_and_comm/topology_concepts/topology_types.html)**
+- **[Topology Types](topology_types.html)**
- The Apache Geode topology options allow you to scale horizontally and vertically.
+ The <%=vars.product_name_long%> topology options allow you to scale horizontally and vertically.
-- **[Planning Topology and Communication](../../topologies_and_comm/topology_concepts/member_communication.html)**
+- **[Planning Topology and Communication](member_communication.html)**
- Create a topology plan and a detailed list of machines and communication ports that your members will use. Configure your Apache Geode systems and the communication between systems.
+ Create a topology plan and a detailed list of machines and communication ports that your members will use. Configure your <%=vars.product_name_long%> systems and the communication between systems.
-- **[How Member Discovery Works](../../topologies_and_comm/topology_concepts/how_member_discovery_works.html)**
+- **[How Member Discovery Works](how_member_discovery_works.html)**
- Apache Geode provides various options for member discovery within a distributed system and between clients and servers.
+ <%=vars.product_name_long%> provides various options for member discovery within a distributed system and between clients and servers.
-- **[How Communication Works](../../topologies_and_comm/topology_concepts/how_communication_works.html)**
+- **[How Communication Works](how_communication_works.html)**
- Geode uses a combination of TCP and UDP unicast and multicast for communication between members. You can change the default behavior to optimize communication for your system.
+ <%=vars.product_name%> uses a combination of TCP and UDP unicast and multicast for communication between members. You can change the default behavior to optimize communication for your system.
-- **[Using Bind Addresses](../../topologies_and_comm/topology_concepts/using_bind_addresses.html)**
+- **[Using Bind Addresses](using_bind_addresses.html)**
- You use a bind address configuration to send network traffic through non-default network cards and to distribute the load of network traffic for Geode across multiple cards. If no bind address setting is found, Geode uses the host machine's default address.
+ You use a bind address configuration to send network traffic through non-default network cards and to distribute the load of network traffic for <%=vars.product_name%> across multiple cards. If no bind address setting is found, <%=vars.product_name%> uses the host machine's default address.
-- **[Choosing Between IPv4 and IPv6](../../topologies_and_comm/topology_concepts/IPv4_and_IPv6.html)**
+- **[Choosing Between IPv4 and IPv6](IPv4_and_IPv6.html)**
- By default, Apache Geode uses Internet Protocol version 4 for Geode address specifications. You can switch to Internet Protocol version 6 if all your machines support it. You may lose performance, so you need to understand the costs of making the switch.
+ By default, <%=vars.product_name_long%> uses Internet Protocol version 4 for <%=vars.product_name%> address specifications. You can switch to Internet Protocol version 6 if all your machines support it. You may lose performance, so you need to understand the costs of making the switch.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/how_communication_works.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/how_communication_works.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/how_communication_works.html.md.erb
index 9739e10..6c7cd8e 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/how_communication_works.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/how_communication_works.html.md.erb
@@ -19,37 +19,37 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Geode uses a combination of TCP and UDP unicast and multicast for communication between members. You can change the default behavior to optimize communication for your system.
+<%=vars.product_name%> uses a combination of TCP and UDP unicast and multicast for communication between members. You can change the default behavior to optimize communication for your system.
Client/server communication and gateway sender to gateway receiver communication uses TCP/IP sockets. The server listens for client communication at a published address and the client establishes the connection, sending its location. Similarly, the gateway receiver listens for gateway sender communication and the connection is established between sites.
-In peer systems, for general messaging and region operations distribution, Geode uses either TCP or UDP unicast. The default is TCP. You can use TCP or UDP unicast for all communications or you can use it as the default but then can target specific regions to use UDP multicast for operations distribution. The best combination for your installation depends in large part on your data use and event messaging.
+In peer systems, for general messaging and region operations distribution, <%=vars.product_name%> uses either TCP or UDP unicast. The default is TCP. You can use TCP or UDP unicast for all communications or you can use it as the default but then can target specific regions to use UDP multicast for operations distribution. The best combination for your installation depends in large part on your data use and event messaging.
## <a id="how_communication_works__section_4402A20FEEC04055A0EEF6FEE82C116D" class="no-quick-link"></a>TCP
TCP (Transmission Control Protocol) provides reliable in-order delivery of the system messages. TCP is more appropriate than UDP if the data is partitioned, if the distributed system is small, or if network loads are unpredictable. TCP is preferable to UDP unicast in smaller distributed systems because it implements more reliable communications at the operating system level than UDP and its performance can be substantially faster than UDP. As the size of the distributed system increases, however, the relatively small overhead of UDP makes it the better choice. TCP adds new threads and sockets to every member, causing more overhead as the system grows.
**Note:**
-Even when Geode is configured to use UDP for messaging, Geode uses a TCP connection when attempting to detect failed members. See [Failure Detection and Membership Views](../../managing/network_partitioning/failure_detection.html#concept_CFD13177F78C456095622151D6EE10EB) for more details. In addition, the TCP connection's ping is not used for keep alive purposes; it is only used to detect failed members. See [TCP/IP KeepAlive Configuration](../../managing/monitor_tune/socket_tcp_keepalive.html#topic_jvc_pw3_34) for TCP keep alive configuration.
+Even when <%=vars.product_name%> is configured to use UDP for messaging, <%=vars.product_name%> uses a TCP connection when attempting to detect failed members. See [Failure Detection and Membership Views](../../managing/network_partitioning/failure_detection.html#concept_CFD13177F78C456095622151D6EE10EB) for more details. In addition, the TCP connection's ping is not used for keep alive purposes; it is only used to detect failed members. See [TCP/IP KeepAlive Configuration](../../managing/monitor_tune/socket_tcp_keepalive.html#topic_jvc_pw3_34) for TCP keep alive configuration.
## <a id="how_communication_works__section_E2D56EE03B54435BA9F04B8550F00534" class="no-quick-link"></a>UDP Unicast and Multicast
UDP (User Datagram Protocol) is a connectionless protocol which uses far fewer resources than TCP. Adding another process to the distributed system incurs little overhead for UDP messaging. UDP on its own is not reliable however, and messages are restricted in size to 64k bytes or less, including overhead for message headers. Large messages must be fragmented and transmitted as multiple datagram messages. Consequently, UDP is slower than TCP in many cases and unusable in other cases if network traffic is unpredictable or heavily congested.
-UDP is used in Geode for both unicast and multicast messaging. Geode implements retransmission protocols to ensure proper delivery of messages over UDP.
+UDP is used in <%=vars.product_name%> for both unicast and multicast messaging. <%=vars.product_name%> implements retransmission protocols to ensure proper delivery of messages over UDP.
## <a id="how_communication_works__section_F2393EE1280749F4B59E2558AA907526" class="no-quick-link"></a>UDP Unicast
-UDP unicast is the alternative to TCP for general messaging. UDP is more appropriate than TCP for unicast messaging when there are a large number of processes in the distributed system, the network is not congested, cached objects are small, and applications can give the cache enough processing time to read from the network. If you disable TCP, Geode uses UDP for unicast messaging.
+UDP unicast is the alternative to TCP for general messaging. UDP is more appropriate than TCP for unicast messaging when there are a large number of processes in the distributed system, the network is not congested, cached objects are small, and applications can give the cache enough processing time to read from the network. If you disable TCP, <%=vars.product_name%> uses UDP for unicast messaging.
-For each member, Geode selects a unique port for UDP unicast communication. You can restrict the range used for the selection by setting `membership-port-range` in the `gemfire.properties` file. Example:
+For each member, <%=vars.product_name%> selects a unique port for UDP unicast communication. You can restrict the range used for the selection by setting `membership-port-range` in the `gemfire.properties` file. Example:
``` pre
membership-port-range=1024-60000
```
**Note:**
-In addition to UDP port configuration, the `membership-port-range` property defines the TCP port used for failure detection. See the [Reference](../../reference/book_intro.html#reference) for a description of the Geode property.
+In addition to UDP port configuration, the `membership-port-range` property defines the TCP port used for failure detection. See the [Reference](../../reference/book_intro.html#reference) for a description of the <%=vars.product_name%> property.
## <a id="how_communication_works__section_15F9EEDD65374F3E9D26C5A960D9D9D3" class="no-quick-link"></a>UDP Multicast
@@ -59,4 +59,4 @@ When multicast is enabled for a region, all processes in the distributed system
Multicast is most appropriate when the majority of processes in a distributed system are using the same cache regions and need to get updates for them, such as when the processes define replicated regions or have their regions configured to receive all events.
-Even if you use multicast for a region, Geode will send unicast messages when appropriate. If data is partitioned, multicast is not a useful option. Even with multicast enabled, partitioned regions still use unicast for almost all purposes.
+Even if you use multicast for a region, <%=vars.product_name%> will send unicast messages when appropriate. If data is partitioned, multicast is not a useful option. Even with multicast enabled, partitioned regions still use unicast for almost all purposes.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/how_member_discovery_works.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/how_member_discovery_works.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/how_member_discovery_works.html.md.erb
index 7123c9d..56174d4 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/how_member_discovery_works.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/how_member_discovery_works.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Apache Geode provides various options for member discovery within a distributed system and between clients and servers.
+<%=vars.product_name_long%> provides various options for member discovery within a distributed system and between clients and servers.
- [Peer Member Discovery](how_member_discovery_works.html#how_member_discovery_works__section_F2B8EBF2909440BD90B4CDEE0CAA0C2A)
- [Standalone Member](how_member_discovery_works.html#how_member_discovery_works__section_E26DFAFE9E994C0C9A489E325E345816)
@@ -27,7 +27,7 @@ Apache Geode provides various options for member discovery within a distributed
## <a id="how_member_discovery_works__section_F2B8EBF2909440BD90B4CDEE0CAA0C2A" class="no-quick-link"></a>Peer Member Discovery
-Peer member discovery is what defines a distributed system. All applications and cache servers that use the same settings for peer discovery are members of the same distributed system. Each system member has a unique identity and knows the identities of the other members. A member can belong to only one distributed system at a time. Once they have found each other, members communicate directly, independent of the discovery mechanism. In peer discovery, Geode uses a membership coordinator to manage member joins and departures.
+Peer member discovery is what defines a distributed system. All applications and cache servers that use the same settings for peer discovery are members of the same distributed system. Each system member has a unique identity and knows the identities of the other members. A member can belong to only one distributed system at a time. Once they have found each other, members communicate directly, independent of the discovery mechanism. In peer discovery, <%=vars.product_name%> uses a membership coordinator to manage member joins and departures.
Members discover each other using one or more locators. A locator provides both discovery and load balancing services. Peer locators manage a dynamic list of distributed system members. New members connect to one of the locators to retrieve the member list, which it uses to join the system.
@@ -38,7 +38,7 @@ Multiple locators ensure the most stable start up and availability for your dist
## <a id="how_member_discovery_works__section_E26DFAFE9E994C0C9A489E325E345816" class="no-quick-link"></a>Standalone Member
-The standalone member has no peers, does no peer discovery, and so does not use locators. It creates a distributed system connection only to access the Geode caching features. Running standalone has a faster startup and is appropriate for any member that is isolated from other applications. The primary use case is for client applications. Standalone members can be accessed and monitored if you enable the member to become a JMX Manager.
+The standalone member has no peers, does no peer discovery, and so does not use locators. It creates a distributed system connection only to access the <%=vars.product_name%> caching features. Running standalone has a faster startup and is appropriate for any member that is isolated from other applications. The primary use case is for client applications. Standalone members can be accessed and monitored if you enable the member to become a JMX Manager.
## <a id="how_member_discovery_works__section_37DE53BDCDB541618C6DF4E47A1F2B73" class="no-quick-link"></a>Client Discovery of Servers
@@ -53,8 +53,8 @@ You do not need to run any special processes to use locators for server discover
## <a id="how_member_discovery_works__section_1CB9D1439346415FB630E9DCD373CAC9" class="no-quick-link"></a>Multi-site Discovery
-In a multi-site (WAN) configuration, a Geode cluster uses locators to discover remote Geode clusters as well as to discover local Geode members. Each locator in a WAN configuration uniquely identifies the local cluster to which it belongs, and it can also identify locators in remote Geode clusters to which it will connect for WAN distribution.
+In a multi-site (WAN) configuration, a <%=vars.product_name%> cluster uses locators to discover remote <%=vars.product_name%> clusters as well as to discover local <%=vars.product_name%> members. Each locator in a WAN configuration uniquely identifies the local cluster to which it belongs, and it can also identify locators in remote <%=vars.product_name%> clusters to which it will connect for WAN distribution.
-When a locator starts up, it contacts each remote locator to exchange information about the available locators and gateway receiver configurations in the remote cluster. In addition to sharing information about its own cluster, a locator shares information that it has obtained from all other connected clusters. Each time a new locator starts up or an existing locator shuts down, the changed information is broadcast to other connected Geode clusters across the WAN.
+When a locator starts up, it contacts each remote locator to exchange information about the available locators and gateway receiver configurations in the remote cluster. In addition to sharing information about its own cluster, a locator shares information that it has obtained from all other connected clusters. Each time a new locator starts up or an existing locator shuts down, the changed information is broadcast to other connected <%=vars.product_name%> clusters across the WAN.
See [Discovery for Multi-Site Systems](multisite_overview.html#topic_1742957C8D4B4F7590847EB8DB6CD4F7) for more information.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/how_multisite_systems_work.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/how_multisite_systems_work.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/how_multisite_systems_work.html.md.erb
index bbdd813..f5ca063 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/how_multisite_systems_work.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/how_multisite_systems_work.html.md.erb
@@ -19,26 +19,26 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-The Apache Geode multi-site implementation connects disparate distributed systems. The systems act as one when they are coupled, and they act as independent systems when communication between sites fails. The coupling is tolerant of weak or slow links between distributed system sites. A wide-area network (WAN) is the main use case for the multi-site topology.
+The <%=vars.product_name_long%> multi-site implementation connects disparate distributed systems. The systems act as one when they are coupled, and they act as independent systems when communication between sites fails. The coupling is tolerant of weak or slow links between distributed system sites. A wide-area network (WAN) is the main use case for the multi-site topology.
-- **[Overview of Multi-site Caching](../../topologies_and_comm/topology_concepts/multisite_overview.html#topic_70045702D3994BC692E75102CE01BD7C)**
+- **[Overview of Multi-site Caching](multisite_overview.html#topic_70045702D3994BC692E75102CE01BD7C)**
A multi-site installation consists of two or more distributed systems that are loosely coupled. Each site manages its own distributed system, but region data is distributed to remote sites using one or more logical connections.
-- **[Consistency for WAN Updates](../../topologies_and_comm/topology_concepts/multisite_overview.html#topic_C74A0961937640B199396DC925D8D782)**
+- **[Consistency for WAN Updates](multisite_overview.html#topic_C74A0961937640B199396DC925D8D782)**
- Geode ensures that all copies of a region eventually reach a consistent state on all members and clients that host the region, including Geode members that distribute region events across a WAN.
+ <%=vars.product_name%> ensures that all copies of a region eventually reach a consistent state on all members and clients that host the region, including <%=vars.product_name%> members that distribute region events across a WAN.
-- **[Discovery for Multi-Site Systems](../../topologies_and_comm/topology_concepts/multisite_overview.html#topic_1742957C8D4B4F7590847EB8DB6CD4F7)**
+- **[Discovery for Multi-Site Systems](multisite_overview.html#topic_1742957C8D4B4F7590847EB8DB6CD4F7)**
- Each Geode cluster in a WAN configuration uses locators to discover remote clusters as well as local members.
+ Each <%=vars.product_name%> cluster in a WAN configuration uses locators to discover remote clusters as well as local members.
-- **[Gateway Senders](../../topologies_and_comm/topology_concepts/multisite_overview.html#topic_9AA37B43642D4DE19072CA3367C849BA)**
+- **[Gateway Senders](multisite_overview.html#topic_9AA37B43642D4DE19072CA3367C849BA)**
- A Geode cluster uses a *gateway sender* to distribute region events to another, remote Geode cluster. You can create multiple gateway sender configurations to distribute region events to multiple remote clusters, and/or to distribute region events concurrently to another remote cluster.
+ A <%=vars.product_name%> cluster uses a *gateway sender* to distribute region events to another, remote <%=vars.product_name%> cluster. You can create multiple gateway sender configurations to distribute region events to multiple remote clusters, and/or to distribute region events concurrently to another remote cluster.
-- **[Gateway Receivers](../../topologies_and_comm/topology_concepts/multisite_overview.html#topic_4DB3D9CF01AD4F4899457D1250468D00)**
+- **[Gateway Receivers](multisite_overview.html#topic_4DB3D9CF01AD4F4899457D1250468D00)**
- A gateway receiver configures a physical connection for receiving region events from gateway senders in one or more remote Geode clusters.
+ A gateway receiver configures a physical connection for receiving region events from gateway senders in one or more remote <%=vars.product_name%> clusters.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/how_server_discovery_works.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/how_server_discovery_works.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/how_server_discovery_works.html.md.erb
index 4abcd8a..78dc35c 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/how_server_discovery_works.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/how_server_discovery_works.html.md.erb
@@ -19,10 +19,10 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Apache Geode locators provide reliable and flexible server discovery services for your clients. You can use all servers for all client requests, or group servers according to function, with the locators directing each client request to the right group of servers.
+<%=vars.product_name_long%> locators provide reliable and flexible server discovery services for your clients. You can use all servers for all client requests, or group servers according to function, with the locators directing each client request to the right group of servers.
<a id="how_server_discovery_works__section_91AC081D4C48408B9ABA40430F161E73"></a>
-By default, Geode clients and servers discover each other on a predefined port (40404) on the localhost. This works, but is not typically the way you would deploy a client/server configuration. The recommended solution is to use one or more dedicated locators. A locator provides both discovery and load balancing services. With server locators, clients are configured with a locator list and locators maintain a dynamic server list. The locator listens at an address and port for connecting clients and gives the clients server information. The clients are configured with locator information and have no configuration specific to the servers.
+By default, <%=vars.product_name%> clients and servers discover each other on a predefined port (40404) on the localhost. This works, but is not typically the way you would deploy a client/server configuration. The recommended solution is to use one or more dedicated locators. A locator provides both discovery and load balancing services. With server locators, clients are configured with a locator list and locators maintain a dynamic server list. The locator listens at an address and port for connecting clients and gives the clients server information. The clients are configured with locator information and have no configuration specific to the servers.
## <a id="how_server_discovery_works__section_95B62F09EF954A99ABBDEBC2756812E3" class="no-quick-link"></a>Basic Configuration
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/how_the_pool_manages_connections.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/how_the_pool_manages_connections.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/how_the_pool_manages_connections.html.md.erb
index c0c93ab..b14f0e3 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/how_the_pool_manages_connections.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/how_the_pool_manages_connections.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-The server pools in your Apache Geode client processes manage all client connection requests to the server tier. To make the best use of the pool functionality, you should understand how the pool manages the server connections.
+The server pools in your <%=vars.product_name_long%> client processes manage all client connection requests to the server tier. To make the best use of the pool functionality, you should understand how the pool manages the server connections.
<a id="how_the_pool_manages_connections__section_2C419926908B4A3599FF0B8EAB7E69A1"></a>
Client/server communication is done in two distinct ways. Each kind of communication uses a different type of connection for maximum performance and availability.
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/member_communication.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/member_communication.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/member_communication.html.md.erb
index 2826224..5d15ac7 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/member_communication.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/member_communication.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Create a topology plan and a detailed list of machines and communication ports that your members will use. Configure your Apache Geode systems and the communication between systems.
+Create a topology plan and a detailed list of machines and communication ports that your members will use. Configure your <%=vars.product_name_long%> systems and the communication between systems.
## <a id="membership_and_communication__section_AC0D7685A2CA4999A40BCEFD514BF599" class="no-quick-link"></a>Determine Protocols and Addresses
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/topology_types.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/topology_types.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/topology_types.html.md.erb
index fbc51ca..8bdbb4d 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/topology_types.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/topology_types.html.md.erb
@@ -19,9 +19,9 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-The Apache Geode topology options allow you to scale horizontally and vertically.
+The <%=vars.product_name_long%> topology options allow you to scale horizontally and vertically.
-Apache Geode provides a variety of cache topologies:
+<%=vars.product_name_long%> provides a variety of cache topologies:
- At the core of all systems is the single, peer-to-peer distributed system.
- For horizontal and vertical scaling, you can combine individual systems into client/server and multi-site (WAN) topologies:
@@ -30,19 +30,19 @@ Apache Geode provides a variety of cache topologies:
## <a id="concept_7628F498DB534A2D8A99748F5DA5DC94__section_333142A36A3E4AF7A1EC31856ED99FCA" class="no-quick-link"></a>Peer-to-Peer Configuration
-The peer-to-peer distributed system is the building block for all Geode installations. Peer-to-peer alone is the simplest topology. Each cache instance, or member, directly communicates with every other member in the distributed system. This cache configuration is primarily designed for applications that need to embed a cache within the application process space and participate in a cluster. A typical example is an application server cluster in which the application and the cache are co-located and share the same heap.
+The peer-to-peer distributed system is the building block for all <%=vars.product_name%> installations. Peer-to-peer alone is the simplest topology. Each cache instance, or member, directly communicates with every other member in the distributed system. This cache configuration is primarily designed for applications that need to embed a cache within the application process space and participate in a cluster. A typical example is an application server cluster in which the application and the cache are co-located and share the same heap.
<img src="../../images_svg/p2p_topology.svg" id="concept_7628F498DB534A2D8A99748F5DA5DC94__image_vzs_qwn_4r" class="image" />
## <a id="concept_7628F498DB534A2D8A99748F5DA5DC94__section_38F7D763AE32466299DC5B7DB9E71C61" class="no-quick-link"></a>Client/Server Configuration
-The client/server topology is the model for vertical scaling, where clients typically host a small subset of the data in the application process space and delegate to the server system for the rest. Compared to peer-to-peer by itself, the client/server architecture provides better data isolation, high fetch performance, and more scalability. If data distribution will put a very heavy load on the network, a client/server architecture usually gives better performance. In any client/server installation, the server system is itself a peer-to-peer system, with data distributed between servers. A client system has a connection pool, which it uses to communicate with servers and other Geode members. A client may also contain a local cache.
+The client/server topology is the model for vertical scaling, where clients typically host a small subset of the data in the application process space and delegate to the server system for the rest. Compared to peer-to-peer by itself, the client/server architecture provides better data isolation, high fetch performance, and more scalability. If data distribution will put a very heavy load on the network, a client/server architecture usually gives better performance. In any client/server installation, the server system is itself a peer-to-peer system, with data distributed between servers. A client system has a connection pool, which it uses to communicate with servers and other <%=vars.product_name%> members. A client may also contain a local cache.
<img src="../../images_svg/cs_topology.svg" id="concept_7628F498DB534A2D8A99748F5DA5DC94__image_073094D7ED05419A9EE8E6AE552BE3F3" class="image" />
## <a id="concept_7628F498DB534A2D8A99748F5DA5DC94__section_566EC05894D6461AA0E7DD7B065D457B" class="no-quick-link"></a>Multi-site Configuration
-For horizontal scaling, you can use a loosely coupled multi-site topology. With multi-site, multiple Geode systems are loosely coupled, generally across geographical distances with slower connections, such as with a WAN. This topology provides better performance than the tight coupling of a single system, and greater independence between locations, so that each site can function on its own if the connection or remote site become unavailable. In a multi-site installation, each individual site is a peer-to-peer or Client/Server system.
+For horizontal scaling, you can use a loosely coupled multi-site topology. With multi-site, multiple <%=vars.product_name%> systems are loosely coupled, generally across geographical distances with slower connections, such as with a WAN. This topology provides better performance than the tight coupling of a single system, and greater independence between locations, so that each site can function on its own if the connection or remote site become unavailable. In a multi-site installation, each individual site is a peer-to-peer or Client/Server system.
<img src="../../images/consistent_multisite.png" id="concept_7628F498DB534A2D8A99748F5DA5DC94__image_6501FD66F0F94273A1F7EEE5747B3925" class="image" />
http://git-wip-us.apache.org/repos/asf/geode/blob/e2c3d531/geode-docs/topologies_and_comm/topology_concepts/using_bind_addresses.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/topologies_and_comm/topology_concepts/using_bind_addresses.html.md.erb b/geode-docs/topologies_and_comm/topology_concepts/using_bind_addresses.html.md.erb
index 833e3fa..b9f0130 100644
--- a/geode-docs/topologies_and_comm/topology_concepts/using_bind_addresses.html.md.erb
+++ b/geode-docs/topologies_and_comm/topology_concepts/using_bind_addresses.html.md.erb
@@ -19,10 +19,10 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-You use a bind address configuration to send network traffic through non-default network cards and to distribute the load of network traffic for Geode across multiple cards. If no bind address setting is found, Geode uses the host machine's default address.
+You use a bind address configuration to send network traffic through non-default network cards and to distribute the load of network traffic for <%=vars.product_name%> across multiple cards. If no bind address setting is found, <%=vars.product_name%> uses the host machine's default address.
<a id="using_bind_addresses__section_6063D5004787488A90EC03085991F902"></a>
-Host machines transmit data to the network and receive data from the network through one or more network cards, also referred to as network interface cards (NIC) or LAN cards. A host with more than one card is referred to as a multi-homed host. On multi-homed hosts, one network card is used by default. You can use bind addresses to configure your Geode members to use non-default network cards on a multi-homed host.
+Host machines transmit data to the network and receive data from the network through one or more network cards, also referred to as network interface cards (NIC) or LAN cards. A host with more than one card is referred to as a multi-homed host. On multi-homed hosts, one network card is used by default. You can use bind addresses to configure your <%=vars.product_name%> members to use non-default network cards on a multi-homed host.
**Note:**
When you specify a non-default card address for a process, all processes that connect to it need to use the same address in their connection settings. For example, if you use bind addresses for your server locators, you must use the same addresses to configure the server pools in your clients.
@@ -31,12 +31,12 @@ Use IPv4 or IPv6 numeric address specifications for your bind address settings.
## <a id="using_bind_addresses__section_63589355AB684F739145E9185806D023" class="no-quick-link"></a>Peer and Server Communication
-You can configure peer, and server communication so that each communication type uses its own address or types use the same address. If no setting is found for a specific communication type, Geode uses the host machine's default address.
+You can configure peer, and server communication so that each communication type uses its own address or types use the same address. If no setting is found for a specific communication type, <%=vars.product_name%> uses the host machine's default address.
**Note:**
Bind addresses set through the APIs, like `CacheServer` and `DistributedSystem`, take precedence over the settings discussed here. If your settings are not working, check to make sure there are no bind address settings being done through API calls.
-This table lists the settings used for peer and server communication, ordered by precedence. For example, for server communication, Geode searches first for the cache-server bind address, then the `gfsh start server` `server-bind-address` setting, and so on until a setting is found or all possibilities are exhausted.
+This table lists the settings used for peer and server communication, ordered by precedence. For example, for server communication, <%=vars.product_name%> searches first for the cache-server bind address, then the `gfsh start server` `server-bind-address` setting, and so on until a setting is found or all possibilities are exhausted.
| Property Setting Ordered by Precedence | Peer | Server | Gateway Receiver | Syntax |
|------------------------------------------------------|------|--------|------------------|---------------------------------------------------|
@@ -66,7 +66,7 @@ bind-address=192.0.2.0
If you are using multi-site (WAN) topology, you can also configure gateway receiver communication (in addition to peer and server communication) so that each communication type uses its own address.
-This table lists the settings used for peer, server, and gateway receiver communication, ordered by precedence. For example, for gateway receiver communication, Geode searches first for a `cache.xml` `<gateway-receiver>` `bind-address` setting. If that is not set, Geode searches for the `gfsh start server` `server-bind-address` setting, and so on until a setting is found or all possibilities are exhausted.
+This table lists the settings used for peer, server, and gateway receiver communication, ordered by precedence. For example, for gateway receiver communication, <%=vars.product_name%> searches first for a `cache.xml` `<gateway-receiver>` `bind-address` setting. If that is not set, <%=vars.product_name%> searches for the `gfsh start server` `server-bind-address` setting, and so on until a setting is found or all possibilities are exhausted.
| Property Setting Ordered by Precedence | Peer | Server | Gateway Receiver | Syntax |
|------------------------------------------------------|------|--------|------------------|---------------------------------------------------|
@@ -105,7 +105,7 @@ Set the locator bind address using one of these methods:
gfsh>start locator --name=my_locator --bind-address=ip-address-to-bind --port=portNumber
```
-- Inside a Geode application, take one of the following actions:
+- Inside a <%=vars.product_name%> application, take one of the following actions:
- Automatically start a co-located locator using the gemfire property `start-locator`, and specifying the bind address for it in that property setting.
- Use `org.apache.geode.distributed.LocatorLauncher` API to start the locator inside your code. Use the `LocatorLauncher.Builder` class to construct an instance of the `LocatorLauncher`, use the `setBindAddress` method to specify the IP address to use and then use the start() method to start a Locator service embedded in your Java application process.