You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@geode.apache.org by bs...@apache.org on 2017/08/22 22:36:16 UTC
[14/48] geode git commit: GEODE-3395 Variable-ize product version and
name in user guide - Developing
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/distributed_regions/how_region_versioning_works.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/distributed_regions/how_region_versioning_works.html.md.erb b/geode-docs/developing/distributed_regions/how_region_versioning_works.html.md.erb
index 9911d31..83fedc1 100644
--- a/geode-docs/developing/distributed_regions/how_region_versioning_works.html.md.erb
+++ b/geode-docs/developing/distributed_regions/how_region_versioning_works.html.md.erb
@@ -21,32 +21,32 @@ limitations under the License.
<a id="topic_7A4B6C6169BD4B1ABD356294F744D236"></a>
-Geode performs different consistency checks depending on the type of region you have configured.
+<%=vars.product_name%> performs different consistency checks depending on the type of region you have configured.
## <a id="topic_7A4B6C6169BD4B1ABD356294F744D236__section_B090F5FB87D84104A7BE4BCEA6BAE6B7" class="no-quick-link"></a>Partitioned Region Consistency
-For a partitioned region, Geode maintains consistency by routing all updates on a given key to the Geode member that holds the primary copy of that key. That member holds a lock on the key while distributing updates to other members that host a copy of the key. Because all updates to a partitioned region are serialized on the primary Geode member, all members apply the updates in the same order and consistency is maintained at all times. See [Understanding Partitioning](../partitioned_regions/how_partitioning_works.html).
+For a partitioned region, <%=vars.product_name%> maintains consistency by routing all updates on a given key to the <%=vars.product_name%> member that holds the primary copy of that key. That member holds a lock on the key while distributing updates to other members that host a copy of the key. Because all updates to a partitioned region are serialized on the primary <%=vars.product_name%> member, all members apply the updates in the same order and consistency is maintained at all times. See [Understanding Partitioning](../partitioned_regions/how_partitioning_works.html).
## <a id="topic_7A4B6C6169BD4B1ABD356294F744D236__section_72DFB366C8F14ADBAF2A136669ECAB1E" class="no-quick-link"></a>Replicated Region Consistency
-For a replicated region, any member that hosts the region can update a key and distribute that update to other members without locking the key. It is possible that two members can update the same key at the same time (a concurrent update). It is also possible that, due to network latency, an update in one member is distributed to other members at a later time, after those members have already applied more recent updates to the key (an out-of-order update). By default, Geode members perform conflict checking before applying region updates in order to detect and consistently resolve concurrent and out-of-order updates. Conflict checking ensures that region data eventually becomes consistent on all members that host the region. The conflict checking behavior for replicated regions is summarized as follows:
+For a replicated region, any member that hosts the region can update a key and distribute that update to other members without locking the key. It is possible that two members can update the same key at the same time (a concurrent update). It is also possible that, due to network latency, an update in one member is distributed to other members at a later time, after those members have already applied more recent updates to the key (an out-of-order update). By default, <%=vars.product_name%> members perform conflict checking before applying region updates in order to detect and consistently resolve concurrent and out-of-order updates. Conflict checking ensures that region data eventually becomes consistent on all members that host the region. The conflict checking behavior for replicated regions is summarized as follows:
- If two members update the same key at the same time, conflict checking ensures that all members eventually apply the same value, which is the value of one of the two concurrent updates.
- If a member receives an out-of-order update (an update that is received after one or more recent updates were applied), conflict checking ensures that the out-of-order update is discarded and not applied to the cache.
-[How Consistency Checking Works for Replicated Regions](#topic_C5B74CCDD909403C815639339AA03758) and [How Destroy and Clear Operations Are Resolved](#topic_321B05044B6641FCAEFABBF5066BD399) provide more details about how Geode performs conflict checking when applying an update.
+[How Consistency Checking Works for Replicated Regions](#topic_C5B74CCDD909403C815639339AA03758) and [How Destroy and Clear Operations Are Resolved](#topic_321B05044B6641FCAEFABBF5066BD399) provide more details about how <%=vars.product_name%> performs conflict checking when applying an update.
## <a id="topic_7A4B6C6169BD4B1ABD356294F744D236__section_313045F430EE459CB411CAAE7B00F3D8" class="no-quick-link"></a>Non-Replicated Regions and Client Cache Consistency
When a member receives an update for an entry in a non-replicated region and applies an update, it performs conflict checking in the same way as for a replicated region. However, if the member initiates an operation on an entry that is not present in the region, it first passes that operation to a member that hosts a replicate. The member that hosts the replica generates and provides the version information necessary for subsequent conflict checking. See [How Consistency Checking Works for Replicated Regions](#topic_C5B74CCDD909403C815639339AA03758).
-Client caches also perform consistency checking in the same way when they receive an update for a region entry. However, all region operations that originate in the client cache are first passed onto an available Geode server, which generates the version information necessary for subsequent conflict checking.
+Client caches also perform consistency checking in the same way when they receive an update for a region entry. However, all region operations that originate in the client cache are first passed onto an available <%=vars.product_name%> server, which generates the version information necessary for subsequent conflict checking.
## <a id="topic_B64891585E7F4358A633C792F10FA23E" class="no-quick-link"></a>Configuring Consistency Checking
-Geode enables consistency checking by default. You cannot disable consistency checking for persistent regions. For all other regions, you can explicitly enable or disable consistency checking by setting the `concurrency-checks-enabled` region attribute in `cache.xml` to "true" or "false."
+<%=vars.product_name%> enables consistency checking by default. You cannot disable consistency checking for persistent regions. For all other regions, you can explicitly enable or disable consistency checking by setting the `concurrency-checks-enabled` region attribute in `cache.xml` to "true" or "false."
-All Geode members that host a region must use the same `concurrency-checks-enabled` setting for that region.
+All <%=vars.product_name%> members that host a region must use the same `concurrency-checks-enabled` setting for that region.
A client cache can disable consistency checking for a region even if server caches enable consistency checking for the same region. This configuration ensures that the client sees all events for the region, but it does not prevent the client cache region from becoming out-of-sync with the server cache.
@@ -65,21 +65,21 @@ If you cannot support the additional overhead in your deployment, you can disabl
## <a id="topic_C5B74CCDD909403C815639339AA03758" class="no-quick-link"></a>How Consistency Checking Works for Replicated Regions
-Each region stores version and timestamp information for use in conflict detection. Geode members use the recorded information to detect and resolve conflicts consistently before applying a distributed update.
+Each region stores version and timestamp information for use in conflict detection. <%=vars.product_name%> members use the recorded information to detect and resolve conflicts consistently before applying a distributed update.
<a id="topic_C5B74CCDD909403C815639339AA03758__section_763B071061C94D1E82E8883325294547"></a>
-By default, each entry in a region stores the ID of the Geode member that last updated the entry, as well as a version stamp for the entry that is incremented each time an update occurs. The version information is stored in each local entry, and the version stamp is distributed to other Geode members when the local entry is updated.
+By default, each entry in a region stores the ID of the <%=vars.product_name%> member that last updated the entry, as well as a version stamp for the entry that is incremented each time an update occurs. The version information is stored in each local entry, and the version stamp is distributed to other <%=vars.product_name%> members when the local entry is updated.
-A Geode member or client that receives an update message first compares the update version stamp with the version stamp recorded in its local cache. If the update version stamp is larger, it represents a newer version of the entry, so the receiving member applies the update locally and updates the version information. A smaller update version stamp indicates an out-of-order update, which is discarded.
+A <%=vars.product_name%> member or client that receives an update message first compares the update version stamp with the version stamp recorded in its local cache. If the update version stamp is larger, it represents a newer version of the entry, so the receiving member applies the update locally and updates the version information. A smaller update version stamp indicates an out-of-order update, which is discarded.
-An identical version stamp indicates that multiple Geode members updated the same entry at the same time. To resolve a concurrent update, a Geode member always applies (or keeps) the region entry that has the highest membership ID; the region entry having the lower membership ID is discarded.
+An identical version stamp indicates that multiple <%=vars.product_name%> members updated the same entry at the same time. To resolve a concurrent update, a <%=vars.product_name%> member always applies (or keeps) the region entry that has the highest membership ID; the region entry having the lower membership ID is discarded.
**Note:**
-When a Geode member discards an update message (either for an out-of-order update or when resolving a concurrent update), it does not pass the discarded event to an event listener for the region. You can track the number of discarded updates for each member using the `conflatedEvents` statistic. See [Geode Statistics List](../../reference/statistics_list.html#statistics_list). Some members may discard an update while other members apply the update, depending on the order in which each member receives the update. For this reason, the `conflatedEvents` statistic differs for each Geode member. The example below describes this behavior in more detail.
+When a <%=vars.product_name%> member discards an update message (either for an out-of-order update or when resolving a concurrent update), it does not pass the discarded event to an event listener for the region. You can track the number of discarded updates for each member using the `conflatedEvents` statistic. See [<%=vars.product_name%> Statistics List](../../reference/statistics_list.html#statistics_list). Some members may discard an update while other members apply the update, depending on the order in which each member receives the update. For this reason, the `conflatedEvents` statistic differs for each <%=vars.product_name%> member. The example below describes this behavior in more detail.
-The following example shows how a concurrent update is handled in a distributed system of three Geode members. Assume that Members A, B, and C have membership IDs of 1, 2, and 3, respectively. Each member currently stores an entry, X, in their caches at version C2 (the entry was last updated by member C):
+The following example shows how a concurrent update is handled in a distributed system of three <%=vars.product_name%> members. Assume that Members A, B, and C have membership IDs of 1, 2, and 3, respectively. Each member currently stores an entry, X, in their caches at version C2 (the entry was last updated by member C):
-**Step 1:** An application updates entry X on Geode member A at the same time another application updates entry X on member C. Each member increments the version stamp for the entry and records the version stamp with their member ID in their local caches. In this case the entry was originally at version C2, so each member updates the version to 3 (A3 and C3, respectively) in their local caches.
+**Step 1:** An application updates entry X on <%=vars.product_name%> member A at the same time another application updates entry X on member C. Each member increments the version stamp for the entry and records the version stamp with their member ID in their local caches. In this case the entry was originally at version C2, so each member updates the version to 3 (A3 and C3, respectively) in their local caches.
<img src="../../images_svg/region_entry_versions_1.svg" id="topic_C5B74CCDD909403C815639339AA03758__image_nt5_ptw_4r" class="image" />
@@ -101,27 +101,27 @@ At this point, all members that host the region have achieved a consistent state
## <a id="topic_321B05044B6641FCAEFABBF5066BD399" class="no-quick-link"></a>How Destroy and Clear Operations Are Resolved
-When consistency checking is enabled for a region, a Geode member does not immediately remove an entry from the region when an application destroys the entry. Instead, the member retains the entry with its current version stamp for a period of time in order to detect possible conflicts with operations that have occurred. The retained entry is referred to as a *tombstone*. Geode retains tombstones for partitioned regions and non-replicated regions as well as for replicated regions, in order to provide consistency.
+When consistency checking is enabled for a region, a <%=vars.product_name%> member does not immediately remove an entry from the region when an application destroys the entry. Instead, the member retains the entry with its current version stamp for a period of time in order to detect possible conflicts with operations that have occurred. The retained entry is referred to as a *tombstone*. <%=vars.product_name%> retains tombstones for partitioned regions and non-replicated regions as well as for replicated regions, in order to provide consistency.
A tombstone in a client cache or a non-replicated region expires after 8 minutes, at which point the tombstone is immediately removed from the cache.
-A tombstone for a replicated or partitioned region expires after 10 minutes. Expired tombstones are eligible for garbage collection by the Geode member. Garbage collection is automatically triggered after 100,000 tombstones of any type have timed out in the local Geode member. You can optionally set the `gemfire.tombstone-gc-threshold` property to a value smaller than 100000 to perform garbage collection more frequently.
+A tombstone for a replicated or partitioned region expires after 10 minutes. Expired tombstones are eligible for garbage collection by the <%=vars.product_name%> member. Garbage collection is automatically triggered after 100,000 tombstones of any type have timed out in the local <%=vars.product_name%> member. You can optionally set the `gemfire.tombstone-gc-threshold` property to a value smaller than 100000 to perform garbage collection more frequently.
**Note:**
-To avoid out-of-memory errors, a Geode member also initiates garbage collection for tombstones when the amount of free memory drops below 30 percent of total memory.
+To avoid out-of-memory errors, a <%=vars.product_name%> member also initiates garbage collection for tombstones when the amount of free memory drops below 30 percent of total memory.
-You can monitor the total number of tombstones in a cache using the `tombstoneCount` statistic in `CachePerfStats`. The `tombstoneGCCount` statistic records the total number of tombstone garbage collection cycles that a member has performed. `replicatedTombstonesSize` and `nonReplicatedTombstonesSize` show the approximate number of bytes that are currently consumed by tombstones in replicated or partitioned regions, and in non-replicated regions, respectively. See [Geode Statistics List](../../reference/statistics_list.html#statistics_list).
+You can monitor the total number of tombstones in a cache using the `tombstoneCount` statistic in `CachePerfStats`. The `tombstoneGCCount` statistic records the total number of tombstone garbage collection cycles that a member has performed. `replicatedTombstonesSize` and `nonReplicatedTombstonesSize` show the approximate number of bytes that are currently consumed by tombstones in replicated or partitioned regions, and in non-replicated regions, respectively. See [<%=vars.product_name%> Statistics List](../../reference/statistics_list.html#statistics_list).
## <a id="topic_321B05044B6641FCAEFABBF5066BD399__section_4D0140E96A3141EB8D983D0A43464097" class="no-quick-link"></a>About Region.clear() Operations
-Region entry version stamps and tombstones ensure consistency only when individual entries are destroyed. A `Region.clear()` operation, however, operates on all entries in a region at once. To provide consistency for `Region.clear()` operations, Geode obtains a distributed read/write lock for the region, which blocks all concurrent updates to the region. Any updates that were initiated before the clear operation are allowed to complete before the region is cleared.
+Region entry version stamps and tombstones ensure consistency only when individual entries are destroyed. A `Region.clear()` operation, however, operates on all entries in a region at once. To provide consistency for `Region.clear()` operations, <%=vars.product_name%> obtains a distributed read/write lock for the region, which blocks all concurrent updates to the region. Any updates that were initiated before the clear operation are allowed to complete before the region is cleared.
## <a id="topic_32ACFA5542C74F3583ECD30467F352B0" class="no-quick-link"></a>Transactions with Consistent Regions
A transaction that modifies a region having consistency checking enabled generates all necessary version information for region updates when the transaction commits.
-If a transaction modifies a normal, preloaded or empty region, the transaction is first delegated to a Geode member that holds a replicate for the region. This behavior is similar to the transactional behavior for partitioned regions, where the partitioned region transaction is forwarded to a member that hosts the primary for the partitioned region update.
+If a transaction modifies a normal, preloaded or empty region, the transaction is first delegated to a <%=vars.product_name%> member that holds a replicate for the region. This behavior is similar to the transactional behavior for partitioned regions, where the partitioned region transaction is forwarded to a member that hosts the primary for the partitioned region update.
-The limitation for transactions on normal, preloaded or or empty regions is that, when consistency checking is enabled, a transaction cannot perform a `localDestroy` or `localInvalidate` operation against the region. Geode throws an `UnsupportedOperationInTransactionException` exception in such cases. An application should use a `Destroy` or `Invalidate` operation in place of a `localDestroy` or `localInvalidate` when consistency checks are enabled.
+The limitation for transactions on normal, preloaded or or empty regions is that, when consistency checking is enabled, a transaction cannot perform a `localDestroy` or `localInvalidate` operation against the region. <%=vars.product_name%> throws an `UnsupportedOperationInTransactionException` exception in such cases. An application should use a `Destroy` or `Invalidate` operation in place of a `localDestroy` or `localInvalidate` when consistency checks are enabled.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/distributed_regions/how_region_versioning_works_wan.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/distributed_regions/how_region_versioning_works_wan.html.md.erb b/geode-docs/developing/distributed_regions/how_region_versioning_works_wan.html.md.erb
index 275d496..b939ea8 100644
--- a/geode-docs/developing/distributed_regions/how_region_versioning_works_wan.html.md.erb
+++ b/geode-docs/developing/distributed_regions/how_region_versioning_works_wan.html.md.erb
@@ -19,21 +19,21 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-When two or more Geode systems are configured to distribute events over a WAN, each system performs local consistency checking before it distributes an event to a configured gateway sender. Discarded events are not distributed across the WAN.
+When two or more <%=vars.product_name%> systems are configured to distribute events over a WAN, each system performs local consistency checking before it distributes an event to a configured gateway sender. Discarded events are not distributed across the WAN.
-Regions can also be configured to distribute updates to other Geode clusters over a WAN. With a distributed WAN configuration, multiple gateway senders asynchronously queue and send region updates to another Geode cluster. It is possible for multiple sites to send updates to the same region entry at the same time. It is also possible that, due to a slow WAN connection, a cluster might receive region updates after a considerable delay, and after it has applied more recent updates to a region. To ensure that WAN-replicated regions eventually reach a consistent state, Geode first ensures that each cluster performs consistency checking to regions before queuing updates to a gateway sender for WAN distribution. In order words, region conflicts are first detected and resolved in the local cluster, using the techniques described in the previous sections.
+Regions can also be configured to distribute updates to other <%=vars.product_name%> clusters over a WAN. With a distributed WAN configuration, multiple gateway senders asynchronously queue and send region updates to another <%=vars.product_name%> cluster. It is possible for multiple sites to send updates to the same region entry at the same time. It is also possible that, due to a slow WAN connection, a cluster might receive region updates after a considerable delay, and after it has applied more recent updates to a region. To ensure that WAN-replicated regions eventually reach a consistent state, <%=vars.product_name%> first ensures that each cluster performs consistency checking to regions before queuing updates to a gateway sender for WAN distribution. In order words, region conflicts are first detected and resolved in the local cluster, using the techniques described in the previous sections.
-When a Geode cluster in a WAN configuration receives a distributed update, conflict checking is performed to ensure that all sites apply updates in the same way. This ensures that regions eventually reach a consistent state across all Geode clusters. The default conflict checking behavior for WAN-replicated regions is summarized as follows:
+When a <%=vars.product_name%> cluster in a WAN configuration receives a distributed update, conflict checking is performed to ensure that all sites apply updates in the same way. This ensures that regions eventually reach a consistent state across all <%=vars.product_name%> clusters. The default conflict checking behavior for WAN-replicated regions is summarized as follows:
-- If an update is received from the same Geode cluster that last updated the region entry, then there is no conflict and the update is applied.
-- If an update is received from a different Geode cluster than the one that last updated the region entry, then a potential conflict exists. A cluster applies the update only when the update has a timestamp that is later than the timestamp currently recorded in the cache.
+- If an update is received from the same <%=vars.product_name%> cluster that last updated the region entry, then there is no conflict and the update is applied.
+- If an update is received from a different <%=vars.product_name%> cluster than the one that last updated the region entry, then a potential conflict exists. A cluster applies the update only when the update has a timestamp that is later than the timestamp currently recorded in the cache.
**Note:**
-If you use the default conflict checking feature for WAN deployments, you must ensure that all Geode members in all clusters synchronize their system clocks. For example, use a common NTP server for all Geode members that participate in a WAN deployment.
+If you use the default conflict checking feature for WAN deployments, you must ensure that all <%=vars.product_name%> members in all clusters synchronize their system clocks. For example, use a common NTP server for all <%=vars.product_name%> members that participate in a WAN deployment.
As an alternative to the default conflict checking behavior for WAN deployments, you can develop and deploy a custom conflict resolver for handling region events that are distributed over a WAN. Using a custom resolver enables you to handle conflicts using criteria other than, or in addition to, timestamp information. For example, you might always prioritize updates that originate from a particular site, given that the timestamp value is within a certain range.
-When a gateway sender distributes an event to another Geode site, it adds the distributed system ID of the local cluster, as well as a timestamp for the event. In a default configuration, the cluster that receives the event examines the timestamp to determine whether or not the event should be applied. If the timestamp of the update is earlier than the local timestamp, the cluster discards the event. If the timestamp is the same as the local timestamp, then the entry having the highest distributed system ID is applied (or kept).
+When a gateway sender distributes an event to another <%=vars.product_name%> site, it adds the distributed system ID of the local cluster, as well as a timestamp for the event. In a default configuration, the cluster that receives the event examines the timestamp to determine whether or not the event should be applied. If the timestamp of the update is earlier than the local timestamp, the cluster discards the event. If the timestamp is the same as the local timestamp, then the entry having the highest distributed system ID is applied (or kept).
You can override the default consistency checking for WAN events by installing a conflict resolver plug-in for the region. If a conflict resolver is installed, then any event that can potentially cause a conflict (any event that originated from a different distributed system ID than the ID that last modified the entry) is delivered to the conflict resolver. The resolver plug-in then makes the sole determination for which update to apply or keep.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/distributed_regions/locking_in_global_regions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/distributed_regions/locking_in_global_regions.html.md.erb b/geode-docs/developing/distributed_regions/locking_in_global_regions.html.md.erb
index 2dc0c8a..313a19b 100644
--- a/geode-docs/developing/distributed_regions/locking_in_global_regions.html.md.erb
+++ b/geode-docs/developing/distributed_regions/locking_in_global_regions.html.md.erb
@@ -26,7 +26,7 @@ In regions with global scope, locking helps ensure cache consistency.
Locking of regions and entries is done in two ways:
-1. **Implicit**. Geode automatically locks global regions and their data entries during most operations. Region invalidation and destruction do not acquire locks.
+1. **Implicit**. <%=vars.product_name%> automatically locks global regions and their data entries during most operations. Region invalidation and destruction do not acquire locks.
2. **Explicit**. You can use the API to explicitly lock the region and its entries. Do this to guarantee atomicity in tasks with multi-step distributed operations. The `Region` methods `org.apache.geode.cache.Region.getDistributedLock` and `org.apache.geode.cache.Region.getRegionDistributedLock` return instances of `java.util.concurrent.locks.Lock` for a region and a specified key.
**Note:**
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/distributed_regions/managing_distributed_regions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/distributed_regions/managing_distributed_regions.html.md.erb b/geode-docs/developing/distributed_regions/managing_distributed_regions.html.md.erb
index 7d4cf37..0149d96 100644
--- a/geode-docs/developing/distributed_regions/managing_distributed_regions.html.md.erb
+++ b/geode-docs/developing/distributed_regions/managing_distributed_regions.html.md.erb
@@ -57,7 +57,7 @@ Before you begin, understand [Basic Configuration and Programming](../../basic_c
</region-attributes>
```
-4. If you are using `global` scope, program any explicit locking you need in addition to the automated locking provided by Geode.
+4. If you are using `global` scope, program any explicit locking you need in addition to the automated locking provided by <%=vars.product_name%>.
## <a id="configure_distributed_region__section_6F53FB58B8A84D0F8086AFDB08A649F9" class="no-quick-link"></a>Local Destroy and Invalidate in the Replicated Region
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/distributed_regions/region_entry_versions.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/distributed_regions/region_entry_versions.html.md.erb b/geode-docs/developing/distributed_regions/region_entry_versions.html.md.erb
index 9aa8dde..53d1483 100644
--- a/geode-docs/developing/distributed_regions/region_entry_versions.html.md.erb
+++ b/geode-docs/developing/distributed_regions/region_entry_versions.html.md.erb
@@ -22,29 +22,29 @@ limitations under the License.
<a id="topic_CF2798D3E12647F182C2CEC4A46E2045"></a>
-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.
+<%=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.
-- **[Consistency Checking by Region Type](../../developing/distributed_regions/how_region_versioning_works.html#topic_7A4B6C6169BD4B1ABD356294F744D236)**
+- **[Consistency Checking by Region Type](how_region_versioning_works.html#topic_7A4B6C6169BD4B1ABD356294F744D236)**
- Geode performs different consistency checks depending on the type of region you have configured.
+ <%=vars.product_name%> performs different consistency checks depending on the type of region you have configured.
-- **[Configuring Consistency Checking](../../developing/distributed_regions/how_region_versioning_works.html#topic_B64891585E7F4358A633C792F10FA23E)**
+- **[Configuring Consistency Checking](how_region_versioning_works.html#topic_B64891585E7F4358A633C792F10FA23E)**
- Geode enables consistency checking by default. You cannot disable consistency checking for persistent regions. For all other regions, you can explicitly enable or disable consistency checking by setting the `concurrency-checks-enabled` region attribute in `cache.xml` to "true" or "false."
+ <%=vars.product_name%> enables consistency checking by default. You cannot disable consistency checking for persistent regions. For all other regions, you can explicitly enable or disable consistency checking by setting the `concurrency-checks-enabled` region attribute in `cache.xml` to "true" or "false."
-- **[Overhead for Consistency Checks](../../developing/distributed_regions/how_region_versioning_works.html#topic_0BDACA590B2C4974AC9C450397FE70B2)**
+- **[Overhead for Consistency Checks](how_region_versioning_works.html#topic_0BDACA590B2C4974AC9C450397FE70B2)**
Consistency checking requires additional overhead for storing and distributing version and timestamp information, as well as for maintaining destroyed entries for a period of time to meet consistency requirements.
-- **[How Consistency Checking Works for Replicated Regions](../../developing/distributed_regions/how_region_versioning_works.html#topic_C5B74CCDD909403C815639339AA03758)**
+- **[How Consistency Checking Works for Replicated Regions](how_region_versioning_works.html#topic_C5B74CCDD909403C815639339AA03758)**
- Each region stores version and timestamp information for use in conflict detection. Geode members use the recorded information to detect and resolve conflicts consistently before applying a distributed update.
+ Each region stores version and timestamp information for use in conflict detection. <%=vars.product_name%> members use the recorded information to detect and resolve conflicts consistently before applying a distributed update.
-- **[How Destroy and Clear Operations Are Resolved](../../developing/distributed_regions/how_region_versioning_works.html#topic_321B05044B6641FCAEFABBF5066BD399)**
+- **[How Destroy and Clear Operations Are Resolved](how_region_versioning_works.html#topic_321B05044B6641FCAEFABBF5066BD399)**
- When consistency checking is enabled for a region, a Geode member does not immediately remove an entry from the region when an application destroys the entry. Instead, the member retains the entry with its current version stamp for a period of time in order to detect possible conflicts with operations that have occurred. The retained entry is referred to as a *tombstone*. Geode retains tombstones for partitioned regions and non-replicated regions as well as for replicated regions, in order to provide consistency.
+ When consistency checking is enabled for a region, a <%=vars.product_name%> member does not immediately remove an entry from the region when an application destroys the entry. Instead, the member retains the entry with its current version stamp for a period of time in order to detect possible conflicts with operations that have occurred. The retained entry is referred to as a *tombstone*. <%=vars.product_name%> retains tombstones for partitioned regions and non-replicated regions as well as for replicated regions, in order to provide consistency.
-- **[Transactions with Consistent Regions](../../developing/distributed_regions/how_region_versioning_works.html#topic_32ACFA5542C74F3583ECD30467F352B0)**
+- **[Transactions with Consistent Regions](how_region_versioning_works.html#topic_32ACFA5542C74F3583ECD30467F352B0)**
A transaction that modifies a region having consistency checking enabled generates all necessary version information for region updates when the transaction commits.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/chapter_overview.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/chapter_overview.html.md.erb b/geode-docs/developing/events/chapter_overview.html.md.erb
index f5b46f4..1a26c08 100644
--- a/geode-docs/developing/events/chapter_overview.html.md.erb
+++ b/geode-docs/developing/events/chapter_overview.html.md.erb
@@ -19,26 +19,26 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Geode provides versatile and reliable event distribution and handling for your cached data and system member events.
+<%=vars.product_name%> provides versatile and reliable event distribution and handling for your cached data and system member events.
-- **[How Events Work](../../developing/events/how_events_work.html)**
+- **[How Events Work](how_events_work.html)**
- Members in your Geode distributed system receive cache updates from other members through cache events. The other members can be peers to the member, clients or servers or other distributed systems.
+ Members in your <%=vars.product_name%> distributed system receive cache updates from other members through cache events. The other members can be peers to the member, clients or servers or other distributed systems.
-- **[Implementing Geode Event Handlers](../../developing/events/event_handler_overview.html)**
+- **[Implementing <%=vars.product_name%> Event Handlers](event_handler_overview.html)**
You can specify event handlers for region and region entry operations and for administrative events.
-- **[Configuring Peer-to-Peer Event Messaging](../../developing/events/configure_p2p_event_messaging.html)**
+- **[Configuring Peer-to-Peer Event Messaging](configure_p2p_event_messaging.html)**
You can receive events from distributed system peers for any region that is not a local region. Local regions receive only local cache events.
-- **[Configuring Client/Server Event Messaging](../../developing/events/configure_client_server_event_messaging.html)**
+- **[Configuring Client/Server Event Messaging](configure_client_server_event_messaging.html)**
You can receive events from your servers for server-side cache events and query result changes.
-- **[Configuring Multi-Site (WAN) Event Queues](../../developing/events/configure_multisite_event_messaging.html)**
+- **[Configuring Multi-Site (WAN) Event Queues](configure_multisite_event_messaging.html)**
- In a multi-site (WAN) installation, Geode uses gateway sender queues to distribute events for regions that are configured with a gateway sender. AsyncEventListeners also use an asynchronous event queue to distribute events for configured regions. This section describes additional options for configuring the event queues that are used by gateway senders or AsyncEventListener implementations.
+ In a multi-site (WAN) installation, <%=vars.product_name%> uses gateway sender queues to distribute events for regions that are configured with a gateway sender. AsyncEventListeners also use an asynchronous event queue to distribute events for configured regions. This section describes additional options for configuring the event queues that are used by gateway senders or AsyncEventListener implementations.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/configure_client_server_event_messaging.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/configure_client_server_event_messaging.html.md.erb b/geode-docs/developing/events/configure_client_server_event_messaging.html.md.erb
index ebd4a3a..77701bd 100644
--- a/geode-docs/developing/events/configure_client_server_event_messaging.html.md.erb
+++ b/geode-docs/developing/events/configure_client_server_event_messaging.html.md.erb
@@ -72,10 +72,10 @@ To receive entry events in the client from the server:
4. To have events enqueued for your clients during client downtime, configure durable client/server messaging.
5. Write any continuous queries (CQs) that you want to run to receive continuously streaming updates to client queries. CQ events do not update the client cache. If you have dependencies between CQs and/or interest registrations, so that you want the two types of subscription events to arrive as closely together on the client, use a single server pool for everything. Using different pools can lead to time differences in the delivery of events because the pools might use different servers to process and deliver the event messages.
-- **[Configuring Highly Available Servers](../../developing/events/configuring_highly_available_servers.html)**
+- **[Configuring Highly Available Servers](configuring_highly_available_servers.html)**
-- **[Implementing Durable Client/Server Messaging](../../developing/events/implementing_durable_client_server_messaging.html)**
+- **[Implementing Durable Client/Server Messaging](implementing_durable_client_server_messaging.html)**
-- **[Tuning Client/Server Event Messaging](../../developing/events/tune_client_server_event_messaging.html)**
+- **[Tuning Client/Server Event Messaging](tune_client_server_event_messaging.html)**
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/configure_multisite_event_messaging.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/configure_multisite_event_messaging.html.md.erb b/geode-docs/developing/events/configure_multisite_event_messaging.html.md.erb
index 5756652..9fb887a 100644
--- a/geode-docs/developing/events/configure_multisite_event_messaging.html.md.erb
+++ b/geode-docs/developing/events/configure_multisite_event_messaging.html.md.erb
@@ -19,20 +19,20 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-In a multi-site (WAN) installation, Geode uses gateway sender queues to distribute events for regions that are configured with a gateway sender. AsyncEventListeners also use an asynchronous event queue to distribute events for configured regions. This section describes additional options for configuring the event queues that are used by gateway senders or AsyncEventListener implementations.
+In a multi-site (WAN) installation, <%=vars.product_name%> uses gateway sender queues to distribute events for regions that are configured with a gateway sender. AsyncEventListeners also use an asynchronous event queue to distribute events for configured regions. This section describes additional options for configuring the event queues that are used by gateway senders or AsyncEventListener implementations.
<a id="configure_multisite_event_messaging__section_1BBF77E166E84F7CA110385FD03D8453"></a>
Before you begin, set up your multi-site (WAN) installation or configure asynchronous event queues and AsyncEventListener implementations. See [Configuring a Multi-site (WAN) System](../../topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system) or [Implementing an AsyncEventListener for Write-Behind Cache Event Handling](implementing_write_behind_event_handler.html#implementing_write_behind_cache_event_handling).
-- **[Persisting an Event Queue](../../developing/events/configuring_highly_available_gateway_queues.html)**
+- **[Persisting an Event Queue](configuring_highly_available_gateway_queues.html)**
You can configure a gateway sender queue or an asynchronous event queue to persist data to disk similar to the way in which replicated regions are persisted.
-- **[Configuring Dispatcher Threads and Order Policy for Event Distribution](../../developing/events/configuring_gateway_concurrency_levels.html)**
+- **[Configuring Dispatcher Threads and Order Policy for Event Distribution](configuring_gateway_concurrency_levels.html)**
- By default, Geode uses multiple dispatcher threads to process region events simultaneously in a gateway sender queue for distribution between sites, or in an asynchronous event queue for distributing events for write-behind caching. With serial queues, you can also configure the ordering policy for dispatching those events.
+ By default, <%=vars.product_name%> uses multiple dispatcher threads to process region events simultaneously in a gateway sender queue for distribution between sites, or in an asynchronous event queue for distributing events for write-behind caching. With serial queues, you can also configure the ordering policy for dispatching those events.
-- **[Conflating Events in a Queue](../../developing/events/conflate_multisite_gateway_queue.html)**
+- **[Conflating Events in a Queue](conflate_multisite_gateway_queue.html)**
Conflating a queue improves distribution performance. When conflation is enabled, only the latest queued value is sent for a particular key.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/configuring_gateway_concurrency_levels.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/configuring_gateway_concurrency_levels.html.md.erb b/geode-docs/developing/events/configuring_gateway_concurrency_levels.html.md.erb
index e59d3b4..f637064 100644
--- a/geode-docs/developing/events/configuring_gateway_concurrency_levels.html.md.erb
+++ b/geode-docs/developing/events/configuring_gateway_concurrency_levels.html.md.erb
@@ -19,9 +19,9 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-By default, Geode uses multiple dispatcher threads to process region events simultaneously in a gateway sender queue for distribution between sites, or in an asynchronous event queue for distributing events for write-behind caching. With serial queues, you can also configure the ordering policy for dispatching those events.
+By default, <%=vars.product_name%> uses multiple dispatcher threads to process region events simultaneously in a gateway sender queue for distribution between sites, or in an asynchronous event queue for distributing events for write-behind caching. With serial queues, you can also configure the ordering policy for dispatching those events.
-By default, a gateway sender queue or asynchronous event queue uses 5 dispatcher threads per queue. This provides support for applications that have the ability to process queued events concurrently for distribution to another Geode site or listener. If your application does not require concurrent distribution, or if you do not have enough resources to support the requirements of multiple dispatcher threads, then you can configure a single dispatcher thread to process a queue.
+By default, a gateway sender queue or asynchronous event queue uses 5 dispatcher threads per queue. This provides support for applications that have the ability to process queued events concurrently for distribution to another <%=vars.product_name%> site or listener. If your application does not require concurrent distribution, or if you do not have enough resources to support the requirements of multiple dispatcher threads, then you can configure a single dispatcher thread to process a queue.
- [Using Multiple Dispatcher Threads to Process a Queue](configuring_gateway_concurrency_levels.html#concept_6C52A037E39E4FD6AE4C6A982A4A1A85__section_20E8EFCE89EB4DC7AA822D03C8E0F470)
- [Performance and Memory Considerations](configuring_gateway_concurrency_levels.html#concept_6C52A037E39E4FD6AE4C6A982A4A1A85__section_C4C83B5C0FDD4913BA128365EE7E4E35)
@@ -30,9 +30,9 @@ By default, a gateway sender queue or asynchronous event queue uses 5 dispatcher
## <a id="concept_6C52A037E39E4FD6AE4C6A982A4A1A85__section_20E8EFCE89EB4DC7AA822D03C8E0F470" class="no-quick-link"></a>Using Multiple Dispatcher Threads to Process a Queue
-When multiple dispatcher threads are configured for a parallel queue, Geode simply uses multiple threads to process the contents of each individual queue. The total number of queues that are created is still determined by the number of Geode members that host the region.
+When multiple dispatcher threads are configured for a parallel queue, <%=vars.product_name%> simply uses multiple threads to process the contents of each individual queue. The total number of queues that are created is still determined by the number of <%=vars.product_name%> members that host the region.
-When multiple dispatcher threads are configured for a serial queue, Geode creates an additional copy of the queue for each thread on each member that hosts the queue. To obtain the maximum throughput, increase the number of dispatcher threads until your network is saturated.
+When multiple dispatcher threads are configured for a serial queue, <%=vars.product_name%> creates an additional copy of the queue for each thread on each member that hosts the queue. To obtain the maximum throughput, increase the number of dispatcher threads until your network is saturated.
The following diagram illustrates a serial gateway sender queue that is configured with multiple dispatcher threads.
<img src="../../images/MultisiteConcurrency_WAN_Gateway.png" id="concept_6C52A037E39E4FD6AE4C6A982A4A1A85__image_093DAC58EBEE456485562C92CA79899F" class="image" width="624" />
@@ -48,8 +48,8 @@ When a serial gateway sender or an asynchronous event queue uses multiple dispat
When using multiple `dispatcher-threads` (greater than 1) with a serial event queue, you can also configure the `order-policy` that those threads use to distribute events from the queue. The valid order policy values are:
-- **key (default)**. All updates to the same key are distributed in order. Geode preserves key ordering by placing all updates to the same key in the same dispatcher thread queue. You typically use key ordering when updates to entries have no relationship to each other, such as for an application that uses a single feeder to distribute stock updates to several other systems.
-- **thread**. All region updates from a given thread are distributed in order. Geode preserves thread ordering by placing all region updates from the same thread into the same dispatcher thread queue. In general, use thread ordering when updates to one region entry affect updates to another region entry.
+- **key (default)**. All updates to the same key are distributed in order. <%=vars.product_name%> preserves key ordering by placing all updates to the same key in the same dispatcher thread queue. You typically use key ordering when updates to entries have no relationship to each other, such as for an application that uses a single feeder to distribute stock updates to several other systems.
+- **thread**. All region updates from a given thread are distributed in order. <%=vars.product_name%> preserves thread ordering by placing all region updates from the same thread into the same dispatcher thread queue. In general, use thread ordering when updates to one region entry affect updates to another region entry.
- **partition**. All region events that share the same partitioning key are distributed in order. Specify partition ordering when applications use a [PartitionResolver](/releases/latest/javadoc/org/apache/geode/cache/PartitionResolver.html) to implement [custom partitioning](../partitioned_regions/using_custom_partition_resolvers.html). With partition ordering, all entries that share the same "partitioning key" (RoutingObject) are placed into the same dispatcher thread queue.
You cannot configure the `order-policy` for a parallel event queue, because parallel queues cannot preserve event ordering for regions. Only the ordering of events for a given partition (or in a given queue of a distributed region) can be preserved.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/configuring_highly_available_gateway_queues.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/configuring_highly_available_gateway_queues.html.md.erb b/geode-docs/developing/events/configuring_highly_available_gateway_queues.html.md.erb
index 28339e2..3f570ef 100644
--- a/geode-docs/developing/events/configuring_highly_available_gateway_queues.html.md.erb
+++ b/geode-docs/developing/events/configuring_highly_available_gateway_queues.html.md.erb
@@ -23,7 +23,7 @@ You can configure a gateway sender queue or an asynchronous event queue to persi
<a id="configuring_highly_available_gateway_queues__section_7EB2A7E38B074AAAA06D22C59687CB8A"></a>
Persisting a queue provides high availability for the event messaging that the sender performs. For example, if a persistent gateway sender queue exits for any reason, when the member that hosts the sender restarts it automatically reloads the queue and resumes sending messages. If an asynchronous event queue exits for any reason, write-back caching can resume where it left off when the queue is brought back online.
-Geode persists an event queue if you set the `enable-persistence` attribute to true. The queue is persisted to the disk store specified in the queue's `disk-store-name` attribute, or to the default disk store if you do not specify a store name.
+<%=vars.product_name%> persists an event queue if you set the `enable-persistence` attribute to true. The queue is persisted to the disk store specified in the queue's `disk-store-name` attribute, or to the default disk store if you do not specify a store name.
You must configure the event queue to use persistence if you are using persistent regions. The use of non-persistent event queues with persistent regions is not supported.
@@ -69,7 +69,7 @@ In the example below the gateway sender queue uses "diskStoreA" for persistence
--maximum-queue-memory=100
```
-If you were to configure 10 dispatcher threads for the serial gateway sender, then the total maximum memory for the gateway sender queue would be 1000MB on each Geode member that hosted the sender, because Geode creates a separate copy of the queue per thread..
+If you were to configure 10 dispatcher threads for the serial gateway sender, then the total maximum memory for the gateway sender queue would be 1000MB on each <%=vars.product_name%> member that hosted the sender, because <%=vars.product_name%> creates a separate copy of the queue per thread..
The following example shows a similar configuration for an asynchronous event queue:
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/configuring_highly_available_servers.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/configuring_highly_available_servers.html.md.erb b/geode-docs/developing/events/configuring_highly_available_servers.html.md.erb
index 48cd174..d78221d 100644
--- a/geode-docs/developing/events/configuring_highly_available_servers.html.md.erb
+++ b/geode-docs/developing/events/configuring_highly_available_servers.html.md.erb
@@ -50,6 +50,6 @@ The following table describes the different values for the subscription-redundan
| > 0 | Sets the precise number of secondary servers to use for backup to the primary. |
| -1 | Every server that is not the primary is to be used as a secondary. |
-- **[Highly Available Client/Server Event Messaging](../../developing/events/ha_event_messaging_whats_next.html)**
+- **[Highly Available Client/Server Event Messaging](ha_event_messaging_whats_next.html)**
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/event_handler_overview.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/event_handler_overview.html.md.erb b/geode-docs/developing/events/event_handler_overview.html.md.erb
index 22a053f..868a063 100644
--- a/geode-docs/developing/events/event_handler_overview.html.md.erb
+++ b/geode-docs/developing/events/event_handler_overview.html.md.erb
@@ -1,6 +1,4 @@
----
-title: Implementing Geode Event Handlers
----
+<% set_title("Implementing", product_name, "Event Handlers") %>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/filtering_multisite_events.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/filtering_multisite_events.html.md.erb b/geode-docs/developing/events/filtering_multisite_events.html.md.erb
index 505cd9c..3ee6ac5 100644
--- a/geode-docs/developing/events/filtering_multisite_events.html.md.erb
+++ b/geode-docs/developing/events/filtering_multisite_events.html.md.erb
@@ -19,21 +19,21 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-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.
You can implement and deploy two different types of filter for multi-site events:
- `GatewayEventFilter`. A `GatewayEventFilter` implementation determines whether a region event is placed in a gateway sender queue and/or whether an event in a gateway queue is distributed to a remote site. You can optionally add one or more `GatewayEventFilter` implementations to a gateway sender, etiher in the `cache.xml` configuration file or using the Java API.
- Geode makes a synchronous call to the filter's `beforeEnqueue` method before it places a region event in the gateway sender queue. The filter returns a boolean value that specifies whether the event should be added to the queue.
+ <%=vars.product_name%> makes a synchronous call to the filter's `beforeEnqueue` method before it places a region event in the gateway sender queue. The filter returns a boolean value that specifies whether the event should be added to the queue.
- Geode asynchronously calls the filter's `beforeTransmit` method to determine whether the gateway sender dispatcher thread should distribute the event to a remote gateway receiver.
+ <%=vars.product_name%> asynchronously calls the filter's `beforeTransmit` method to determine whether the gateway sender dispatcher thread should distribute the event to a remote gateway receiver.
- For events that are distributed to another site, Geode calls the listener's `afterAcknowledgement` method to indicate that is has received an ack from the remote site after the event was received.
+ For events that are distributed to another site, <%=vars.product_name%> calls the listener's `afterAcknowledgement` method to indicate that is has received an ack from the remote site after the event was received.
-- GatewayTransportFilter. Use a `GatewayTransportFilter` implementation to process the TCP stream that sends a batch of events that is distributed from one Geode cluster to another over a WAN. A `GatewayTransportFilter` is typically used to perform encryption or compression on the data that distributed. You install the same `GatewayTransportFilter` implementation on both a gateway sender and gateway receiver.
+- GatewayTransportFilter. Use a `GatewayTransportFilter` implementation to process the TCP stream that sends a batch of events that is distributed from one <%=vars.product_name%> cluster to another over a WAN. A `GatewayTransportFilter` is typically used to perform encryption or compression on the data that distributed. You install the same `GatewayTransportFilter` implementation on both a gateway sender and gateway receiver.
- When a gateway sender processes a batch of events for distribution, Geode delivers the stream to the `getInputStream` method of a configured `GatewayTransportFilter` implementation. The filter processes and returns the stream, which is then transmitted to the gateway receiver. When the gateway receiver receives the batch, Geode calls the `getOutputStream` method of a configured filter, which again processes and returns the stream so that the events can be applied in the local cluster.
+ When a gateway sender processes a batch of events for distribution, <%=vars.product_name%> delivers the stream to the `getInputStream` method of a configured `GatewayTransportFilter` implementation. The filter processes and returns the stream, which is then transmitted to the gateway receiver. When the gateway receiver receives the batch, <%=vars.product_name%> calls the `getOutputStream` method of a configured filter, which again processes and returns the stream so that the events can be applied in the local cluster.
## <a id="topic_E97BB68748F14987916CD1A50E4B4542__section_E20B4A8A98FD4EDAAA8C14B8059AA7F7" class="no-quick-link"></a>Configuring Multi-Site Event Filters
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/how_cache_events_work.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/how_cache_events_work.html.md.erb b/geode-docs/developing/events/how_cache_events_work.html.md.erb
index e54371a..4492092 100644
--- a/geode-docs/developing/events/how_cache_events_work.html.md.erb
+++ b/geode-docs/developing/events/how_cache_events_work.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-When a region or entry operation is performed, Geode distributes the associated events in the distributed system according to system and cache configurations.
+When a region or entry operation is performed, <%=vars.product_name%> distributes the associated events in the distributed system according to system and cache configurations.
<a id="how_cache_events_work__section_7864A275FDB549FD8E2D046DD59CB9F4"></a>
Install a cache listener for a region in each system member that needs to receive notification of region and entry changes.
@@ -68,4 +68,4 @@ In the following figure:
## <a id="how_cache_events_work__section_B4DCA51DDF7F44699E7355277172BEF0" class="no-quick-link"></a>Managing Events in Multi-threaded Applications
-For partitioned regions, Geode guarantees ordering of events across threads, but for distributed regions it doesn’t. For multi-threaded applications that create distributed regions, you need to use your application synchronization to make sure that one operation completes before the next one begins. Distribution through the distributed-no-ack queue can work with multiple threads if you set the `conserve-sockets` attribute to true. Then the threads share one queue, preserving the order of the events in distributed regions. Different threads can invoke the same listener, so if you allow different threads to send events, it can result in concurrent invocations of the listener. This is an issue only if the threads have some shared state - if they are incrementing a serial number, for example, or adding their events to a log queue. Then you need to make your code thread safe.
+For partitioned regions, <%=vars.product_name%> guarantees ordering of events across threads, but for distributed regions it doesn’t. For multi-threaded applications that create distributed regions, you need to use your application synchronization to make sure that one operation completes before the next one begins. Distribution through the distributed-no-ack queue can work with multiple threads if you set the `conserve-sockets` attribute to true. Then the threads share one queue, preserving the order of the events in distributed regions. Different threads can invoke the same listener, so if you allow different threads to send events, it can result in concurrent invocations of the listener. This is an issue only if the threads have some shared state - if they are incrementing a serial number, for example, or adding their events to a log queue. Then you need to make your code thread safe.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/how_client_server_distribution_works.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/how_client_server_distribution_works.html.md.erb b/geode-docs/developing/events/how_client_server_distribution_works.html.md.erb
index be7e4f2..88e7698 100644
--- a/geode-docs/developing/events/how_client_server_distribution_works.html.md.erb
+++ b/geode-docs/developing/events/how_client_server_distribution_works.html.md.erb
@@ -122,7 +122,7 @@ Once interest is registered, the server continually monitors region activities a
## <a id="how_client_server_distribution_works__section_928BB60066414BEB9FAA7FB3120334A3" class="no-quick-link"></a>Server Failover
-When a server hosting a subscription queue fails, the queueing responsibilities pass to another server. How this happens depends on whether the new server is a secondary server. In any case, all failover activities are carried out automatically by the Geode system.
+When a server hosting a subscription queue fails, the queueing responsibilities pass to another server. How this happens depends on whether the new server is a secondary server. In any case, all failover activities are carried out automatically by the <%=vars.product_name%> system.
- **Non-HA failover:** The client fails over without high availability if it is not configured for redundancy or if all secondaries also fail before new secondaries can be initialized. As soon as it can attach to a server, the client goes through an automatic reinitialization process. In this process, the failover code on the client side silently destroys all entries of interest to the client and refetches them from the new server, essentially reinitializing the client cache from the new server’s cache. For the notify all configuration, this clears and reloads all of the entries for the client regions that are connected to the server. For notify by subscription, it clears and reloads only the entries in the region interest lists. To reduce failover noise, the events caused by the local entry destruction and refetching are blocked by the failover code and do not reach the client cache listeners. Because of this, your clients could receive some out-of-sequence events during and af
ter a server failover. For example, entries that exist on the failed server and not on its replacement are destroyed and never recreated during a failover. Because the destruction events are blocked, the client ends up with entries removed from its cache with no associated destroy events.
- **HA failover:** If your client pool is configured with redundancy and a secondary server is available at the time the primary fails, the failover is invisible to the client. The secondary server resumes queueing activities as soon as the primary loss is detected. The secondary might resend a few events, which are discarded automatically by the client message tracking activities.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/how_events_work.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/how_events_work.html.md.erb b/geode-docs/developing/events/how_events_work.html.md.erb
index 2ac899a..291bbb2 100644
--- a/geode-docs/developing/events/how_events_work.html.md.erb
+++ b/geode-docs/developing/events/how_events_work.html.md.erb
@@ -19,11 +19,11 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Members in your Geode distributed system receive cache updates from other members through cache events. The other members can be peers to the member, clients or servers or other distributed systems.
+Members in your <%=vars.product_name%> distributed system receive cache updates from other members through cache events. The other members can be peers to the member, clients or servers or other distributed systems.
## <a id="how_events_work__section_6C75098DDBB84944ADE57F2088330D5A" class="no-quick-link"></a>Events Features
-These are the primary features of Geode events:
+These are the primary features of <%=vars.product_name%> events:
- Content-based events
- Asynchronous event notifications with conflation
@@ -46,7 +46,7 @@ Both kinds of events can be generated by a single member operation.
**Note:**
You can handle one of these categories of events in a single system member. You cannot handle both cache and administrative events in a single member.
-Because Geode maintains the order of administrative events and the order of cache events separately, using cache events and administrative events in a single process can cause unexpected results.
+Because <%=vars.product_name%> maintains the order of administrative events and the order of cache events separately, using cache events and administrative events in a single process can cause unexpected results.
## <a id="how_events_work__section_4BCDB22AB927478EBF1035B0DE230DD3" class="no-quick-link"></a>Event Cycle
@@ -92,20 +92,20 @@ During a cache operation, event handlers are called at various stages of the ope
**Note:**
An `EntryEvent` contains both the old value and the new value of the entry, which helps to indicate the value that was replaced by the cache operation on a particular key.
-- **[Peer-to-Peer Event Distribution](../../developing/events/how_cache_events_work.html)**
+- **[Peer-to-Peer Event Distribution](how_cache_events_work.html)**
- When a region or entry operation is performed, Geode distributes the associated events in the distributed system according to system and cache configurations.
+ When a region or entry operation is performed, <%=vars.product_name%> distributes the associated events in the distributed system according to system and cache configurations.
-- **[Client-to-Server Event Distribution](../../developing/events/how_client_server_distribution_works.html)**
+- **[Client-to-Server Event Distribution](how_client_server_distribution_works.html)**
Clients and servers distribute events according to client activities and according to interest registered by the client in server-side cache changes.
-- **[Multi-Site (WAN) Event Distribution](../../developing/events/how_multisite_distribution_works.html)**
+- **[Multi-Site (WAN) Event Distribution](how_multisite_distribution_works.html)**
- Geode distributes a subset of cache events between distributed systems, with a minimum impact on each system's performance. Events are distributed only for regions that you configure to use a gateway sender for distribution.
+ <%=vars.product_name%> distributes a subset of cache events between distributed systems, with a minimum impact on each system's performance. Events are distributed only for regions that you configure to use a gateway sender for distribution.
-- **[List of Event Handlers and Events](../../developing/events/list_of_event_handlers_and_events.html)**
+- **[List of Event Handlers and Events](list_of_event_handlers_and_events.html)**
- Geode provides many types of events and event handlers to help you manage your different data and application needs.
+ <%=vars.product_name%> provides many types of events and event handlers to help you manage your different data and application needs.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/how_multisite_distribution_works.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/how_multisite_distribution_works.html.md.erb b/geode-docs/developing/events/how_multisite_distribution_works.html.md.erb
index 7678e7a..ee518e7 100644
--- a/geode-docs/developing/events/how_multisite_distribution_works.html.md.erb
+++ b/geode-docs/developing/events/how_multisite_distribution_works.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
limitations under the License.
-->
-Geode distributes a subset of cache events between distributed systems, with a minimum impact on each system's performance. Events are distributed only for regions that you configure to use a gateway sender for distribution.
+<%=vars.product_name%> distributes a subset of cache events between distributed systems, with a minimum impact on each system's performance. Events are distributed only for regions that you configure to use a gateway sender for distribution.
## <a id="how_multisite_distribution_works__section_A16562611E094C88B12BC149D5EEEEBA" class="no-quick-link"></a>Queuing Events for Distribution
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/implementing_cache_event_handlers.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/implementing_cache_event_handlers.html.md.erb b/geode-docs/developing/events/implementing_cache_event_handlers.html.md.erb
index 0e639e7..7afcc4d 100644
--- a/geode-docs/developing/events/implementing_cache_event_handlers.html.md.erb
+++ b/geode-docs/developing/events/implementing_cache_event_handlers.html.md.erb
@@ -22,7 +22,7 @@ limitations under the License.
Depending on your installation and configuration, cache events can come from local operations, peers, servers, and remote sites. Event handlers register their interest in one or more events and are notified when the events occur.
<a id="implementing_cache_event_handlers__section_9286E8C6B3C54089888E1680B4F43692"></a>
-For each type of handler, Geode provides a convenience class with empty stubs for the interface callback methods.
+For each type of handler, <%=vars.product_name%> provides a convenience class with empty stubs for the interface callback methods.
**Note:**
Write-behind cache listeners are created by extending the `AsyncEventListener` interface, and they are configured with an `AsyncEventQueue` that you assign to one or more regions.
http://git-wip-us.apache.org/repos/asf/geode/blob/ed9a8fd4/geode-docs/developing/events/implementing_durable_client_server_messaging.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/developing/events/implementing_durable_client_server_messaging.html.md.erb b/geode-docs/developing/events/implementing_durable_client_server_messaging.html.md.erb
index 150a79d..a1d1792 100644
--- a/geode-docs/developing/events/implementing_durable_client_server_messaging.html.md.erb
+++ b/geode-docs/developing/events/implementing_durable_client_server_messaging.html.md.erb
@@ -54,7 +54,7 @@ Use one of the following methods:
The `durable-client-id` indicates that the client is durable and gives the server an identifier to correlate the client to its durable messages. For a non-durable client, this id is an empty string. The ID can be any number that is unique among the clients attached to servers in the same distributed system.
-The `durable-client-timeout` tells the server how long to wait for client reconnect. When this timeout is reached, the server stops storing to the client's message queue and discards any stored messages. The default is 300 seconds. This is a tuning parameter. If you change it, take into account the normal activity of your application, the average size of your messages, and the level of risk you can handle, both in lost messages and in the servers' capacity to store enqueued messages. Assuming that no messages are being removed from the queue, how long can the server run before the queue reaches the maximum capacity? How many durable clients can the server handle? To assist with tuning, use the Geode message queue statistics for durable clients through the disconnect and reconnect cycles.
+The `durable-client-timeout` tells the server how long to wait for client reconnect. When this timeout is reached, the server stops storing to the client's message queue and discards any stored messages. The default is 300 seconds. This is a tuning parameter. If you change it, take into account the normal activity of your application, the average size of your messages, and the level of risk you can handle, both in lost messages and in the servers' capacity to store enqueued messages. Assuming that no messages are being removed from the queue, how long can the server run before the queue reaches the maximum capacity? How many durable clients can the server handle? To assist with tuning, use the <%=vars.product_name%> message queue statistics for durable clients through the disconnect and reconnect cycles.
## <a id="implementing_durable_client_server_messaging__section_BB5DCCE0582E4FE8B62DE473512FC704" class="no-quick-link"></a>Configure Durable Subscriptions and Continuous Queries
@@ -169,7 +169,7 @@ During initialization, the client cache is not blocked from doing operations, so
- Client cache operations by the application.
- Callbacks triggered by replaying old events from the queue
-Geode handles the conflicts between the application and interest registrations so they do not create cache update conflicts. But you must program your event handlers so they don't conflict with current operations. This is true for all event handlers, but it is especially important for those used in durable clients. Your handlers may receive events well after the fact and you must ensure your programming takes that into account.
+<%=vars.product_name%> handles the conflicts between the application and interest registrations so they do not create cache update conflicts. But you must program your event handlers so they don't conflict with current operations. This is true for all event handlers, but it is especially important for those used in durable clients. Your handlers may receive events well after the fact and you must ensure your programming takes that into account.
This figure shows the three concurrent procedures during the initialization process. The application begins operations immediately on the client (step 1), while the client’s cache ready message (also step 1) triggers a series of queue operations on the servers (starting with step 2 on the primary server). At the same time, the client registers interest (step 2 on the client) and receives a response from the server. Message B2 applies to an entry in Region A, so the cache listener handles B2’s event. Because B2 comes before the marker, the client does not apply the update to the cache.