You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@geode.apache.org by db...@apache.org on 2020/10/02 15:30:50 UTC
[geode-native] branch support/1.13 updated: GEODE-8519: User Guide
- Delete 'preserving-data' topics (#664)
This is an automated email from the ASF dual-hosted git repository.
dbarnes pushed a commit to branch support/1.13
in repository https://gitbox.apache.org/repos/asf/geode-native.git
The following commit(s) were added to refs/heads/support/1.13 by this push:
new ed3d984 GEODE-8519: User Guide - Delete 'preserving-data' topics (#664)
ed3d984 is described below
commit ed3d9840613564cfe99540a7ceedadf477ba465a
Author: Dave Barnes <db...@apache.org>
AuthorDate: Fri Oct 2 07:32:36 2020 -0700
GEODE-8519: User Guide - Delete 'preserving-data' topics (#664)
---
.../subscription-properties.html.md.erb | 2 +-
.../continuous-queries.html.md.erb | 4 +-
.../app-ops-during-int-reg.html.md.erb | 34 -----------
.../preserving-data/client-side-config.html.md.erb | 36 ------------
.../config-durable-interest-keys.html.md.erb | 50 -----------------
.../config-durable-reconnect.html.md.erb | 59 --------------------
.../configuring-durable-nc.html.md.erb | 53 ------------------
.../preserving-data/configuring-nc-ha.html.md.erb | 65 ----------------------
.../disconnecting-from-server.html.md.erb | 36 ------------
.../preserving-data/disconnection.html.md.erb | 44 ---------------
.../durable-client-life-cycle.html.md.erb | 44 ---------------
.../durable-client-messaging-req.html.md.erb | 36 ------------
.../durable-client-messaging.html.md.erb | 48 ----------------
.../durable-message-replay.html.md.erb | 44 ---------------
.../high-availability-client-server.html.md.erb | 32 -----------
...mpl-cache-listeners-durable-clients.html.md.erb | 36 ------------
.../preserving-data/initial-operation.html.md.erb | 26 ---------
.../preserving-data/preserving-data.html.md.erb | 38 -------------
.../preserving-data/reconnection.html.md.erb | 49 ----------------
.../sending-cache-ready-message.html.md.erb | 36 ------------
.../sending-periodic-ack.html.md.erb | 48 ----------------
.../using-queue-conflation.html.md.erb | 40 -------------
.../subscription-properties.html.md.erb | 2 +-
.../continuous-queries.html.md.erb | 4 +-
24 files changed, 6 insertions(+), 860 deletions(-)
diff --git a/docs/geode-native-docs-cpp/connection-pools/subscription-properties.html.md.erb b/docs/geode-native-docs-cpp/connection-pools/subscription-properties.html.md.erb
index 5c3ff1b..53f4fbc 100644
--- a/docs/geode-native-docs-cpp/connection-pools/subscription-properties.html.md.erb
+++ b/docs/geode-native-docs-cpp/connection-pools/subscription-properties.html.md.erb
@@ -23,7 +23,7 @@ Each connection pool has a single subscription connection that can be to any ser
When a client registers interest for a region, if the connection pool does not already have a subscription channel, the connection pool sends a message to the server locator, and the server locator chooses servers to host the queue and return those server names to the client. The client then contacts the chosen servers and asks them to create the queue.
-The client maintains at least one connection with each server hosting a queue. If the server does not detect any connections from a non-durable client, it drops the client queue and closes all artifacts for the client. For information about durable client subscriptions, see [Durable Client Messaging](../preserving-data/durable-client-messaging.html#concept_F88B659FB4324F599924F3F2933452B4).
+The client maintains at least one connection with each server hosting a queue. If the server does not detect any connections from a non-durable client, it drops the client queue and closes all artifacts for the client. For information about durable client subscriptions, see [Implementing Durable Client/Server Messaging](/serverman/developing/events/implementing_durable_client_server_messaging.html).
## <a id="subscription-properties__section_294BD33FBDC6454FAD9C5118829EBBA4" class="no-quick-link"></a>Requesting a Subscription Region Queue
diff --git a/docs/geode-native-docs-cpp/continuous-queries.html.md.erb b/docs/geode-native-docs-cpp/continuous-queries.html.md.erb
index 77f56dd..daf2d85 100644
--- a/docs/geode-native-docs-cpp/continuous-queries.html.md.erb
+++ b/docs/geode-native-docs-cpp/continuous-queries.html.md.erb
@@ -37,8 +37,8 @@ to process CQ events is based on the standard <%=vars.product_name%> event handl
server-to-client messaging mechanisms to send events. All tuning of your server-to-client
messaging also tunes the messaging of your CQ events. If your system is configured for high
availability then your CQs are highly available, with seamless failover provided in case of
-server failure (see [High Availability for Client-to-Server Communication](preserving-data/high-availability-client-server.html)).
-If your clients are durable, you can also define any of your CQs as durable (see [Durable Client Messaging](preserving-data/durable-client-messaging.html)).
+server failure (see [Highly Available Client/Server Event Messaging](/serverman/developing/events/ha_event_messaging_whats_next.html)).
+If your clients are durable, you can also define any of your CQs as durable (see [Implementing Durable Client/Server Messaging](/serverman/developing/events/implementing_durable_client_server_messaging.html)).
- **Interest criteria based on data values**. Continuous queries are run against the region's entry values.
Compare this to register interest by reviewing [Registering Interest for Entries](regions/registering-interest-for-entries.html).
diff --git a/docs/geode-native-docs-cpp/preserving-data/app-ops-during-int-reg.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/app-ops-during-int-reg.html.md.erb
deleted file mode 100644
index e133a8e..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/app-ops-during-int-reg.html.md.erb
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Application Operations During Interest Registration
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-As soon as the client creates its regions, the application hosting the client can start cache operations, even while the client is still receiving its interest registration responses.
-
-In that case, application operations take precedence over interest registration responses.
-
-When adding register interest responses to the cache, the following rules are applied:
-
-- If the entry already exists in the cache with a valid value, it is not updated.
-- If the entry is invalid and the register interest response is valid, the valid value is put into the cache.
-- If an entry is marked destroyed, it is not updated. Destroyed entries are removed from the system after the register interest response is completed.
-
-If the interest response does not contain any results because all of those keys are absent from the server’s cache, the client’s cache can start out empty. If the queue contains old messages related to those keys, the events are still replayed in the client’s cache.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/client-side-config.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/client-side-config.html.md.erb
deleted file mode 100644
index e89fa93..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/client-side-config.html.md.erb
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Client-Side Configuration
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-All durable messaging configurations are performed on the client.
-
-- **[Configuring a Durable Client](configuring-durable-nc.html)**
-
- The durable client can be configured in the `geode.properties` file, or in the `CacheFactory::set(name, value)` call.
-
-- **[Configuring Durable Interest in Keys](config-durable-interest-keys.html)**
-
- When a durable client disconnects, its servers keep queuing messages for selected keys. The client indicates which keys by registering durable interest for those keys.
-
-- **[Configuring Durable Client Reconnection](config-durable-reconnect.html)**
-
- You can configure the durable client to obtain an approximate count of pending events upon durable client reconnection. Based on the returned number, you can determine whether to proceed and receive the pending events or to close the cache.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/config-durable-interest-keys.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/config-durable-interest-keys.html.md.erb
deleted file mode 100644
index 04f8601..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/config-durable-interest-keys.html.md.erb
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Configuring Durable Interest in Keys
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-When a durable client disconnects, its servers keep queuing messages for selected keys. The client indicates which keys by registering durable interest for those keys.
-
-This fine-grained control handles the constraints of queue size and memory by saving only the critical messages.
-
-You still register interest for other keys, but not durable interest. When the client is connected to its servers, it receives messages for those non-durable keys. When the client is disconnected, its non-durable interest registrations are deleted but messages that are already in the queue remain there.
-
-For durable clients, all interest registration is done immediately after the regions are created. This is required whether interest registration is durable or not durable. An extra `registerInterest` parameter specified for durable clients indicates whether the registration is durable (true) or not (false).
-
-## API Client Durable Interest List Registration (C++)
-
-The following programmatic example registers durable interest in Key-1. The interest registration happens immediately after region creation and before anything else.
-
-``` pre
-// Durable client interest registration can be
-// durable (true) or nondurable(default).
-VectorOfCacheableKey keys;
-keys.push_back( CacheableString::create("Key-1") );
-regionPtr->registerKeys(keys,true);
-```
-
-<a id="concept_6456354A9AD945C780A5AA864B41B564__section_3DE5872B0888410EB42D52CFB28C79E5"></a>
-You use the typical methods for interest registration and configure notification by subscription on the server as usual. For details, see [Registering Interest for Entries](../client-cache/registering-interest-for-entries.html#registering-interest-for-entries).
-
-**Note:**
-Changing interest registration after the durable client connects the first time can cause data inconsistency and is not recommended.
-
-At restart, if the client doesn't register durable interest for exactly the same keys as before then the entries in the interest list are not copied from the server during the registration. Instead, the client cache starts out empty and entries are added during updates. If no updates come in for an entry, it never shows up in the client cache.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/config-durable-reconnect.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/config-durable-reconnect.html.md.erb
deleted file mode 100644
index 2f6815e..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/config-durable-reconnect.html.md.erb
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Configuring Durable Client Reconnection
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-You can configure a durable client to obtain an approximate count of pending events upon durable client reconnection. Based on the returned number, you can determine whether to proceed and receive the pending events or to close the cache.
-
-Use the `getPendingEventCount` (C++ API) and the `PendingEventCount` (.NET API) property to detect whether the previously registered subscription queue is available upon durable client reconnection and the count of pending events in the queue. Based on the returned results, you can then decide whether to receive the remaining events or close the cache if the number is too large.
-
-For example, consider this code fragment for a client with only the default pool created:
-
-``` pre
-Pool pool = PoolManager.Find("PoolName");
-int pendingEvents = pool.PendingEventCount;
-if (pendingEvents == -2) { // client connected for the first time
- … // continue
-} else if (pendingEvents == -1) { // client reconnected but after the timeout period
- … // handle possible data loss
-} else { // pendingEvents >= 0
- // decide to invoke readyForEvents() or Cache.close(false)/Pool.destroy()
-}
-```
-
-For a client with multiple pools:
-
-``` pre
-int pendingEvents = 0;
-int pendingEvents1 = PoolManager.Find(“pool1”).PendingEventCount;
-pendingEvents += (pendingEvents1 > 0) ? pendingEvents1 : 0;
-int pendingEvents2 = PoolManager.Find(“pool2”).PendingEventCount;
-pendingEvents += (pendingEvents2 > 0) ? pendingEvents2 : 0;
-// process individual pool counts separately
-```
-
-The `getPendingEventCount` method and PendingEventCount property can return the following possible values:
-
-- A value representing a count of events pending at the server. Note that this count is an approximate value based on the time the durable client pool connected or reconnected to the server. Any number of invocations will return the same value.
-- A zero value if there are no events pending at server for this client pool
-- A negative value indicates that no queue is available at the server for the client pool.
- - A value of -1 indicates that the client pool has reconnected to the server after its durable-client-timeout period has elapsed. The pool's subscription queue has been removed possibly causing data loss.
- - A value of -2 indicates that this client pool has connected to server for the first time.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/configuring-durable-nc.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/configuring-durable-nc.html.md.erb
deleted file mode 100644
index 3eb1a37..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/configuring-durable-nc.html.md.erb
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Configuring a Durable Client
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-The durable client can be configured in the `geode.properties` file, or in the `CacheFactory::set(name, value)` call.
-
-- **Durable client ID**—Indicate that the client is durable by giving it a `durable-client-ID`. The servers use this ID to identify the client. For a non-durable client, the `durable-client-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.
-
-- **Durable timeout**—The `durable-timeout` setting specifies how long this client’s servers should wait after the client disconnects before terminating its message queue. During that time, the servers consider the client alive and continue to accumulate messages for it. The default is 300 seconds.
-
-The `durable-timeout` setting is a tuning parameter. When setting the timeout, take into account the normal activity of your application, the average size of your messages, and the level of risk you can handle. Assuming that no messages are being removed from the queue, how long can the application run before the queue reaches the maximum message count? In addition, how long can it run before the queued messages consume all the memory on the client host? How serious is each of those fail [...]
-
-To assist with tuning, <%=vars.product_name%> statistics track message queues for durable clients through the disconnect and reconnect cycles.
-
-When the queue is full, it blocks further operations that add messages until the queue size drops to an acceptable level. Server configuration sets the action to take. See details on server configuration of the queue in the server documentation section [Implementing Durable Client/Server Messaging](geodeman/developing/events/implementing_durable_client_server_messaging.html).
-
-## Configuring a Durable Client Using geode.properties
-
-The following example shows `geode.properties` settings to make the client durable and set the durable timeout to 200seconds.
-
-``` pre
-durable-client-id=31
-durable-timeout=200
-```
-
-## Configuring a Durable Client Through the API (C++)
-
-This programmatic example creates a durable client using the `CacheFactory::set(name, value)`.
-
-``` pre
-// Create durable client's properties using the C++ api
-PropertiesPtr pp = Properties::create();
-pp->insert("durable-client-id", "DurableClientId");
-pp->insert("durable-timeout", std::chrono::seconds(200));
-cacheFactoryPtr = CacheFactory::createCacheFactory(pp);
-```
diff --git a/docs/geode-native-docs-cpp/preserving-data/configuring-nc-ha.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/configuring-nc-ha.html.md.erb
deleted file mode 100644
index 4eceeba..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/configuring-nc-ha.html.md.erb
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Configuring Clients for High Availability
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-Configure high availability by setting the pool attribute `subscription-redundancy` to the number of copies to be maintained.
-
-A client maintains its queue redundancy level at the time of a primary server failure by connecting to additional secondary servers.
-
-Clients can specify the number of secondary servers where the client registers interest and maintains subscription channels, in addition to the subscription channel with the primary server. The secondary servers maintain redundant update queues for the client. If the primary server fails, a secondary becomes a primary to provide uninterrupted messaging to the client. If possible, another secondary is then initialized so the total number of secondaries is not reduced by the failover.
-
-## Setting the Server Redundancy Level in cache.xml
-
-This example sets one redundant server as failover backup to the primary server:
-
-``` pre
-<cache>
- <pool name="examplePool"
- subscription-enabled="true" subscription-redundancy="1">
- <server host="java_servername1" port="java_port1" />
- <server host="java_servername2" port="java_port2" />
- </pool>
- <region name = "ThinClientRegion1" >
- <region-attributes refid="CACHING_PROXY" pool-name="examplePool"/>
- </region>
-</cache>
-```
-
-## Setting the Server Redundancy Level Programmatically
-
-You can set the redundancy level programmatically. This example creates a client cache with two redundant cache servers configured in addition to the primary server.
-
-The server redundancy level can be configured using the pool API. For more information about the pool API, see [Using Connection Pools](../connection-pools/connection-pools.html#using-connection-pools).
-
-``` pre
-PropertiesPtr pp = Properties::create( );
-systemPtr = CacheFactory::createCacheFactory(pp);
-// Create a cache.
-cachePtr = systemPtr->setSubscriptionEnabled(true)
- ->addServer("localhost", 24680)
- ->addServer("localhost", 24681)
- ->addServer("localhost", 24682)
- ->setSubscriptionRedundancy(2)
- ->create();
-```
-
-When failover to a secondary server occurs, a new secondary is added to the redundancy set. If no new secondary server is found, the redundancy level is not satisfied but the failover procedure completes successfully. Any new live server is added as a secondary and interest is registered on it.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/disconnecting-from-server.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/disconnecting-from-server.html.md.erb
deleted file mode 100644
index a480ca8..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/disconnecting-from-server.html.md.erb
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Disconnecting from the Server
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-When a durable client closes its cache and disconnects, it tells the servers whether to maintain its queues.
-
-For this purpose, use the version of `Cache::close` with the boolean `keepalive` parameter set, as shown in the following example. If the setting is true, the servers keep the durable client’s queues and durable subscriptions alive for the timeout period. In addition to in-memory queue retention, the servers can evict the most recent durable client queue updates to disk to reduce memory consumption.
-
-Only the resources and data related to the session are removed, such as port numbers and non-durable subscriptions. If the setting is false, the servers do the same cleanup that they would do for a nondurable client.
-
-``` pre
-// Close the Cache and disconnect with keepalive=true.
-// Server will queue events for durable registrations and CQs
-// When the client reconnects (within a timeout period) and sends
-// "readyForEvents()", the server will deliver all stored events
-cachePtr->close(true);
-```
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/disconnection.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/disconnection.html.md.erb
deleted file mode 100644
index be85e5a..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/disconnection.html.md.erb
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Disconnection
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-While the client and servers are disconnected, their operation varies depending on the circumstances.
-
-## <a id="concept_915EAD135DD942F28A38513097ACB1F1__section_6AB8F4B8993F4EF9B32A93A100F07BEC" class="no-quick-link"></a>Normal disconnect
-
-When a durable client disconnects normally, the `Cache.close` request states whether to maintain the client's message queue and durable subscriptions. The servers stop sending messages to the client and release its connection. See [Disconnecting From the Server](disconnecting-from-server.html#concept_3A9AC62F96FA44DBBB5CCBFD3EA19B56) for more information.
-
-If requested, the servers maintain the queues and durable interest list until the client reconnects or times out. The non-durable interest list is discarded. The servers continue to queue up incoming messages for entries on the durable interest list. All messages that were in the queue when the client disconnected remain in the queue, including messages for entries on the non-durable list.
-
-If the client requests to not have its subscriptions maintained, or if there are no durable subscriptions, the servers unregister the client and perform the same cleanup as for a non-durable client.
-
-## Abnormal disconnect
-
-If the client crashes or loses its connections to all servers, the servers automatically maintain its message queue and durable subscriptions until the client reconnects or times out.
-
-## Client disconnected but operational
-
-If the client operates while it is disconnected, it gets what data it can from the local cache. Since updates are not allowed, the data can become stale. An `UnconnectedException` occurs if an update is attempted.
-
-## Timing out while disconnected
-
-The servers track how long to keep a durable client queue alive based on the `durable-client-timeout` setting. If the client remains disconnected longer than the timeout, the servers unregister the client and do the same cleanup that is performed for a non-durable client. The servers also log an alert. When a timed-out client reconnects, the servers treat it as a new client making its initial connection.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/durable-client-life-cycle.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/durable-client-life-cycle.html.md.erb
deleted file mode 100644
index 880fbd1..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/durable-client-life-cycle.html.md.erb
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Life Cycle of a Durable Client
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-This section discusses the high-level operation of a durable client through initial startup, disconnection, and reconnection.
-
-- **[Initial Operation](initial-operation.html)**
-
- The initial startup of a durable client is similar to the startup of any other client, except that it specifically calls the `Cache.readyForEvents` method when all regions and listeners on the client are ready to process messages from the server.
-
-- **[Disconnection](disconnection.html)**
-
- While the client and servers are disconnected, their operation varies depending on the circumstances.
-
-- **[Reconnection](reconnection.html)**
-
- During initialization, operations on the client cache can come from multiple sources.
-
-- **[Durable Message Replay](durable-message-replay.html)**
-
- When the primary server receives the cache ready message, the servers and client execute a procedure to update the queue and replay the events from the stored messages.
-
-- **[Application Operations During Interest Registration](app-ops-during-int-reg.html)**
-
- As soon as the client creates its regions, the application hosting the client can start cache operations, even while the client is still receiving its interest registration responses.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/durable-client-messaging-req.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/durable-client-messaging-req.html.md.erb
deleted file mode 100644
index a03e054..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/durable-client-messaging-req.html.md.erb
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Durable Client Messaging Requirements
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-The messaging queues used for durable messaging are the same regular messaging queues used for basic server-to-client messaging, with additional requirements.
-
-See the server documentation at [Implementing Durable Client/Server Messaging](geodeman/developing/events/implementing_durable_client_server_messaging.html) for requirements, options, and functionality of messaging queues. If you are using highly available servers, see [High Availability for Client-Server Communication](high-availability-client-server.html#concept_F7A143F51EEA46B28AC612DEB7849D99) for additional requirements.
-
-For durable client messaging, you also need the following:
-
-- **Durable clients**. If the client is durable, the server continues to maintain the client queues when the client disconnects.
- **Note:**
- Redundancy management is handled by the client, so when the client is disconnected from the server the redundancy of client events is not maintained. Even if the servers fail one at a time, so that running clients have time to fail over and pick new secondary servers, an offline durable client cannot fail over. As a result, the client loses its queued messages.
-
-- **Durable interest registration**. A durable client’s interest registrations specify whether its interest in a key is durable. If it is, the servers continue queuing messages for that key while the client is disconnected.
-- **Reconnection conditions.** You can program the durable client to detect whether the previously registered subscription queue is available upon reconnection and determine an approximate count of pending events in the queue. Based on the results, you can then decide whether to receive the remaining events (`Cache.readyForEvents`) or close the cache if the number is too large.
-- **Cache ready message**. When it is ready to receive the stored messages, a durable client must call `Cache.readyForEvents` to send a cache ready message to the server.
-- **Disconnect keepalive specification**. When a durable client disconnects normally, the client must tell the server whether to maintain the message queue or delete it.
-- **Durable client callback method**. If you use cache listeners on the durable clients, you have the option to implement the `afterRegionLive` callback method. This callback is invoked after the durable client connects to its servers, when it has received all of its stored messages and replayed the events.
diff --git a/docs/geode-native-docs-cpp/preserving-data/durable-client-messaging.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/durable-client-messaging.html.md.erb
deleted file mode 100644
index 824d5cc..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/durable-client-messaging.html.md.erb
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Durable Client Messaging
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-You can configure the redundancy level for client queues that are stored on cache servers. This ensures that the client will not lose messages if it loses the connection to its primary server.
-
-Durable messaging allows a disconnected client application to recover its subscribed data when it reconnects to the cache server because the server continues to queue messages for which the client has registered interest.
-
-- **[Durable Client Messaging Requirements](durable-client-messaging-req.html)**
-
- The messaging queues used for durable messaging are the same regular messaging queues used for basic server-to-client messaging, with additional requirements.
-
-- **[Client-Side Configuration](client-side-config.html)**
-
-- **[Sending Cache Ready Messages to the Server](sending-cache-ready-message.html)**
-
- After a durable client connects and initializes its cache, regions, cache listeners, and any interest registration, it invokes `readyForEvents` to indicate to the servers that the client is ready to receive any messages accumulated for it.
-
-- **[Disconnecting from the Server](disconnecting-from-server.html)**
-
- When a durable client closes its cache and disconnects, it tells the servers whether to maintain its queues.
-
-- **[Life Cycle of a Durable Client](durable-client-life-cycle.html)**
-
- This section discusses the high-level operation of a durable client through initial startup, disconnection, and reconnection.
-
-- **[Implementing Cache Listeners for Durable Clients](impl-cache-listeners-durable-clients.html)**
-
- A cache listener for durable clients requires all callback methods to behave properly when stored events are replayed. A cache listener has a callback method, `afterRegionLive`, specifically for durable clients aspects.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/durable-message-replay.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/durable-message-replay.html.md.erb
deleted file mode 100644
index 6f59369..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/durable-message-replay.html.md.erb
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: Durable Message Replay
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-When the primary server receives the cache ready message, the servers and client execute a procedure to update the queue and replay the events from the stored messages.
-
-Durable message replay proceeds as follows. To avoid overwriting current entries with old data, the client does not apply the updates to its cache.
-
-1. The server finds the queue for this durable client ID and updates its information, including the client’s socket and remote ports.
-
- If the client has timed out while it was disconnected, its queues are gone and the server then treats it as a new client. See [Initial Operation](initial-operation.html).
-
-2. All servers that have a queue for this client place a marker in the queue.
-
- Messages in the queue before the marker are considered to have come while the client was disconnected. Messages after the marker are handled normally.
-
-3. The cache server sends the queued messages to the client. This includes any messages that were evicted to disk.
-4. The client receives the messages but does not apply the updates to its cache. If cache listeners are installed, they handle the events. For implications, see [Implementing Cache Listeners for Durable Clients](impl-cache-listeners-durable-clients.html#concept_3BD651087FC4470C8BAB6AFD97AEA689).
-5. The client receives the marker message indicating that all past events have been played back.
-6. The cache server sends the current list of live regions.
-7. In each live region on the client, the marker event triggers the `afterRegionLive` callback.
-
- After the callback, the client begins normal processing of events from the server and applies the updates to its cache.
-
-Even when a new client starts up for the first time, the cache ready markers are inserted in the queues. If messages start coming into the new queues before the servers insert the marker, those messages are considered as having happened while the client was disconnected, and their events are replayed the same as in the reconnect case.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/high-availability-client-server.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/high-availability-client-server.html.md.erb
deleted file mode 100644
index 4995022..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/high-availability-client-server.html.md.erb
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: High Availability for Client-Server Communication
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-The client provides reliable event messaging from cache server to client to prevent data loss during server failover operations. High availability is implemented in the cache server and is configured in the client.
-
-See server documentation at [Configuring Highly Available Servers](geodeman/developing/events/configuring_highly_available_servers.html) for details about configuring a server for high availability.
-
-- **[Configuring Clients for High Availability](configuring-nc-ha.html)**
-
- Configure high availability by setting the pool attribute `subscription-redundancy` to the number of copies maintained.
-
-- **[Sending Periodic Acknowledgment](sending-periodic-ack.html)**
-
- Servers use periodic acknowledgment to reduce the likelihood of duplicate notifications, and to reduce resource usage.
diff --git a/docs/geode-native-docs-cpp/preserving-data/impl-cache-listeners-durable-clients.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/impl-cache-listeners-durable-clients.html.md.erb
deleted file mode 100644
index ae3b520..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/impl-cache-listeners-durable-clients.html.md.erb
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Implementing Cache Listeners for Durable Clients
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-A cache listener for durable clients requires all callback methods to behave properly when stored events are replayed. A cache listener has a callback method, `afterRegionLive`, specifically for durable clients aspects.
-
-For general instructions on implementing a cache listener, see [CacheListener](../client-cache/application-plugins.html#application-plugins__section_3F43B898CD254076B4DD777E9B4CC8F0).
-
-## <a id="concept_3BD651087FC4470C8BAB6AFD97AEA689__section_EC28F9769A554CA28B0E9D2F924BA4C3" class="no-quick-link"></a>Writing Callbacks for Use With Durable Messaging
-
-Durable clients require special attention to cache callbacks generated by the cache listener. During the initialization window when a reconnecting client has a functioning cache but is still receiving the stored messages from the queue, the client can replay events that are long past. These events are not applied to the cache, but they are sent to the cache listener. If the listener’s callbacks invoked by these events make changes to the cache, that could conflict with current operations [...]
-
-Consequently, you need to keep your callback implementations lightweight and not do anything in the cache that could produce incorrect results during this window. For details on implementing callbacks for <%=vars.product_name%> event handlers, see [Implementing Cache Event Handlers](geodeman/developing/events/implementing_cache_event_handlers.html).
-
-## <a id="concept_3BD651087FC4470C8BAB6AFD97AEA689__section_F39E695D88E94D518F3E1778F37FAF11" class="no-quick-link"></a>Implementing the afterRegionLive Method
-
-If you are using cache listeners, you can implement the `afterRegionLive` callback method provided for durable clients. This callback is invoked when the client has received all the old messages that were stored in its queue while it was disconnected. Implementing this method enables you to do application-specific operations when the client has replayed all of these old events.
-
-If you do not wish to use this callback, and your listener is an instance of `CacheListener` (not a `CacheListenerAdapter`), you must implement `afterRegionLive` as a non-operational method.
diff --git a/docs/geode-native-docs-cpp/preserving-data/initial-operation.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/initial-operation.html.md.erb
deleted file mode 100644
index 3ed3831..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/initial-operation.html.md.erb
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Initial Operation
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-The initial startup of a durable client is similar to the startup of any other client, except that it specifically calls the `Cache.readyForEvents` method when all regions and listeners on the client are ready to process messages from the server.
-
-See [Sending the Cache Ready Message to the Server](sending-cache-ready-message.html#concept_C28D015FA85B4EE4B2F8D2DA5FCAFBFF).
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/preserving-data.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/preserving-data.html.md.erb
deleted file mode 100644
index 3792eab..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/preserving-data.html.md.erb
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Preserving Data
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-A server may preserve the data queued and intended to be sent to a client, such that the data is not discarded if communication between the server and client is disrupted. Preservation prevents message loss, which can cause a client to have inconsistent data. Redundant queues and a high availability server implementation may further ensure that queued data is not lost.
-
-There is a tradeoff between the quantity of data that a server must queue and the amount of time that the server maintains and continues to queue data intended for a client that is not communicating with the distributed system. Client configuration specifies the amount of time that the server is to continue queueing messages. High availability permits a secondary server to assume the role of a primary server with respect to queued data in the event that the primary server no longer funct [...]
-
-- **[High Availability for Client-Server Communication](high-availability-client-server.html)**
-
- The client provides reliable event messaging from cache server to client to prevent data loss during server failover operations. High availability is implemented in the cache server and is configured in the client.
-
-- **[Enabling Queue Conflation to Improve Update Performance](using-queue-conflation.html)**
-
- Conflation of entry update messages can reduce the number of update messages a client receives, thereby increasing performance. The client receives only the most recent update for a particular entry key.
-
-- **[Durable Client Messaging](durable-client-messaging.html)**
-
- Configure the redundancy level for client queues that are stored on cache servers. This ensures that the client will not lose messages if it loses the connection to its primary server.
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/reconnection.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/reconnection.html.md.erb
deleted file mode 100644
index 8fc8b5e..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/reconnection.html.md.erb
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: Reconnection
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-During initialization, operations on the client cache can come from multiple sources.
-
-- Cache operations by the application.
-- Results returned by the cache server in response to the client’s interest registrations.
-- Callbacks triggered by replaying old events from the queue.
-
-These procedures can act on the cache concurrently, and the cache is never blocked from doing operations.
-
-<%=vars.product_name%> handles the conflicts between the application and interest registration, but you need to prevent the callback problem. Writing callback methods that do cache operations is never recommended, but it is a particularly bad idea for durable clients, as explained in [Implementing Cache Listeners for Durable Clients](impl-cache-listeners-durable-clients.html).
-
-Program the durable client to perform these steps, in order, when it reconnects:
-
-1. Create the cache and regions. This ensures that all cache listeners are ready. At this point, the application hosting the client can begin cache operations.
-2. Issue its register interest requests. This allows the client cache to be populated with the initial interest registration results. The primary server responds with the current state of those entries if they still exist in the server’s cache.
-3. Call `Cache.readyForEvents`. This tells the servers that all regions and listeners on the client are now ready to process messages from the servers. The cache ready message triggers the queued message replay process on the primary server.
-
-For an example that demonstrates `Cache.readyForEvents`, see [Sending the Cache Ready Message to the Server](sending-cache-ready-message.html#concept_C28D015FA85B4EE4B2F8D2DA5FCAFBFF).
-
-This figure shows the concurrent procedures that occur 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 cache 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.
-
-<a id="concept_38C027837216434CB5DEC84DF56B807E__fig_5A5566FB9EBE4A6D906E9D8FA687B4C5"></a>
-<span class="figtitleprefix">Figure: </span> Initialization of a Reconnected Durable Client
-
-<img src="../images/7-Preserving_Data-2.gif" id="concept_38C027837216434CB5DEC84DF56B807E__image_1B3693DB90D041F193496BA24849D114" class="image" />
-
-Only one region is shown for simplicity, but the messages in the queue could apply to multiple regions. Also, the figure omits the concurrent cache updates on the servers, which would normally be adding more messages to the client's message queue.
diff --git a/docs/geode-native-docs-cpp/preserving-data/sending-cache-ready-message.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/sending-cache-ready-message.html.md.erb
deleted file mode 100644
index 14b6e94..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/sending-cache-ready-message.html.md.erb
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Sending Cache Ready Messages to the Server
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-After a durable client connects and initializes its cache, regions, cache listeners, and any interest registration, it invokes `readyForEvents` to indicate to the servers that the client is ready to receive any messages accumulated for it.
-
-## Durable Client Cache Ready Notification (C++)
-
-The following example shows how to call `readyForEvents`.
-
-``` pre
-// Send ready for event message to server (only for durable clients).
-// Server will send queued events to client after receiving this.
-cachePtr->readyForEvents();
-```
-
-To keep the client from losing events, do not call this method until all regions and listeners are created. For more information, see [Reconnection](reconnection.html#concept_38C027837216434CB5DEC84DF56B807E).
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/sending-periodic-ack.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/sending-periodic-ack.html.md.erb
deleted file mode 100644
index c3f2620..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/sending-periodic-ack.html.md.erb
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Sending Periodic Acknowledgment
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-Servers use periodic acknowledgment to reduce the likelihood of duplicate notifications, and to reduce resource usage.
-
-<a id="concept_868B8082463846DE9F35BBEA56105C82__section_D4375BCCF8A2426BA58073B9549B6F04"></a>
-When redundancy is enabled for high availability and `redundancy-level` is set to 1 or higher, clients send (and servers expect) periodic acknowledgment messages at configurable intervals for notifications they have received. A periodic ack is not sent by the client if there are no unacknowledged notifications at the time.
-
-Use the following system properties in the `geode.properties` file to configure periodic ack.
-
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<tbody>
-<tr class="odd">
-<td><code class="ph codeph">notify-ack-interval</code></td>
-<td><p>Minimum period between two consecutive acknowledgment messages sent from the client to the server. The default setting (in seconds) is 10.</p></td>
-</tr>
-<tr class="even">
-<td><code class="ph codeph">notify-dupcheck-life</code></td>
-<td><p>Minimum time a client continues to track a notification source for duplicates when no new notifications arrive before expiring it. The default setting (in seconds) is 300.</p></td>
-</tr>
-</tbody>
-</table>
-
-The Pool API also provides attributes to configure periodic ack and duplicate message tracking timeout. See `subscription-message-tracking-timeout` and `subscription-ack-interval` in the list of pool attributes under [Configuring Pools for Servers or Locators](../connection-pools/configuring-pools.html#configuring-pools).
-
-
diff --git a/docs/geode-native-docs-cpp/preserving-data/using-queue-conflation.html.md.erb b/docs/geode-native-docs-cpp/preserving-data/using-queue-conflation.html.md.erb
deleted file mode 100644
index 9f45e52..0000000
--- a/docs/geode-native-docs-cpp/preserving-data/using-queue-conflation.html.md.erb
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: Enabling Queue Conflation to Improve Update Performance
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements. See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-Conflation of entry update messages can reduce the number of update messages a client receives, thereby increasing performance. The client receives only the most recent update for a particular entry key.
-
-Conflation is enabled for a cache server region, so all clients receiving updates for a particular region benefit from the conflation. To enable conflation, set the cache server’s `enable-subscription-conflation` region attribute to `true`. This region attribute is `false` by default.
-
-The queue managment code conflates entry updates as part of the enqueue operation. If the previous enqueued item for that key is also an `update` operation, the queue management code removes that previously enqueued update, leaving only the latest update to be sent when event distribution occurs. For high availability, conflation also occurs for any secondary queues.
-
-Only entry `update` messages in a cache server region with `distributed-no-ack` scope are conflated. Region operations and entry operations other than updates are not conflated.
-
-For more information, see the server documentation at [Conflate the Server Subscription Queue](geodeman/developing/events/conflate_server_subscription_queue.html).
-
-## <a id="concept_AEFA04AF9ABD42C0A37ED31806596D24__section_BE506A32A8E44073B197B03AC5232C01" class="no-quick-link"></a>Overriding Queue Conflation Per-Client
-
-Override conflation on a per-client basis by setting the conflate-events property in the client’s `geode.properties` file.
-
-Valid settings are:
-
-- `server`. Uses the server settings.
-- `true`. Conflates everything sent to the client.
-- `false`. Does not conflate anything sent to the client.
diff --git a/docs/geode-native-docs-dotnet/connection-pools/subscription-properties.html.md.erb b/docs/geode-native-docs-dotnet/connection-pools/subscription-properties.html.md.erb
index 5c3ff1b..e9818c7 100644
--- a/docs/geode-native-docs-dotnet/connection-pools/subscription-properties.html.md.erb
+++ b/docs/geode-native-docs-dotnet/connection-pools/subscription-properties.html.md.erb
@@ -23,7 +23,7 @@ Each connection pool has a single subscription connection that can be to any ser
When a client registers interest for a region, if the connection pool does not already have a subscription channel, the connection pool sends a message to the server locator, and the server locator chooses servers to host the queue and return those server names to the client. The client then contacts the chosen servers and asks them to create the queue.
-The client maintains at least one connection with each server hosting a queue. If the server does not detect any connections from a non-durable client, it drops the client queue and closes all artifacts for the client. For information about durable client subscriptions, see [Durable Client Messaging](../preserving-data/durable-client-messaging.html#concept_F88B659FB4324F599924F3F2933452B4).
+The client maintains at least one connection with each server hosting a queue. If the server does not detect any connections from a non-durable client, it drops the client queue and closes all artifacts for the client. For information about durable client subscriptions, see [Implementing Durable Client/Server Messaging](/serverman/developing/events/implementing_durable_client_server_messaging.html)..
## <a id="subscription-properties__section_294BD33FBDC6454FAD9C5118829EBBA4" class="no-quick-link"></a>Requesting a Subscription Region Queue
diff --git a/docs/geode-native-docs-dotnet/continuous-queries.html.md.erb b/docs/geode-native-docs-dotnet/continuous-queries.html.md.erb
index 44dd74e..7904c26 100644
--- a/docs/geode-native-docs-dotnet/continuous-queries.html.md.erb
+++ b/docs/geode-native-docs-dotnet/continuous-queries.html.md.erb
@@ -37,8 +37,8 @@ to process CQ events is based on the standard <%=vars.product_name%> event handl
server-to-client messaging mechanisms to send events. All tuning of your server-to-client
messaging also tunes the messaging of your CQ events. If your system is configured for high
availability then your CQs are highly available, with seamless failover provided in case of
-server failure (see [High Availability for Client-to-Server Communication](preserving-data/high-availability-client-server.html)).
-If your clients are durable, you can also define any of your CQs as durable (see [Durable Client Messaging](preserving-data/durable-client-messaging.html)).
+server failure (see [Highly Available Client/Server Event Messaging](/serverman/developing/events/ha_event_messaging_whats_next.html)).
+If your clients are durable, you can also define any of your CQs as durable (see [Implementing Durable Client/Server Messaging](/serverman/developing/events/implementing_durable_client_server_messaging.html)).
- **Interest criteria based on data values**. Continuous queries are run against the region's entry values.
Compare this to register interest by reviewing [Registering Interest for Entries](regions/registering-interest-for-entries.html).