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 <[email protected]>
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).
