RDoc-2353 How client integrates with the cluster: Update info

Documentation/5.2/Raven.Documentation.Pages/client-api/cluster/.docs.json

@@ -1,31 +1,31 @@
 [
-  {
-    "Path": "how-client-integrates-with-replication-and-cluster.markdown",
-    "Name": "How Client Integrates With Replication and Cluster",
-    "DiscussionId": "b05e7bae-67c2-4271-b222-257b83682288",
-    "Mappings": [
-      {
-        "Version": 3.5,
-        "Key": "client-api/bundles/how-client-integrates-with-replication-bundle"
-      }
-    ]
-  },
-  {
-    "Path": "document-conflicts-in-client-side.markdown",
-    "Name": "Document Conflict Exceptions at Client-Side",
-    "DiscussionId": "e2f7677e-0fdd-4ced-9e2e-d0d6e334bb4d",
-    "Mappings": []
-  },
-  {
-    "Path": "speed-test.markdown",
-    "Name": "Client Speed Test",
-    "DiscussionId": "715a3fc0-888c-4e49-9d2d-f6682cf24d3f",
-    "Mappings": []
-  },
-  {
-    "Path": "health-check.markdown",
-    "Name": "Cluster Node Health Check",
-    "DiscussionId": "e3e9b9f4-5e06-4d9a-a1cf-21b6ab521328",
-    "Mappings": []
-  }
-]
+    {
+        "Path": "how-client-integrates-with-replication-and-cluster.markdown",
+        "Name": "Client Integration with the Cluster",
+        "DiscussionId": "b05e7bae-67c2-4271-b222-257b83682288",
+        "Mappings": [
+            {
+                "Version": 3.5,
+                "Key": "client-api/bundles/how-client-integrates-with-replication-bundle"
+            }
+        ]
+    },
+    {
+        "Path": "document-conflicts-in-client-side.markdown",
+        "Name": "Document Conflict Exceptions at Client-Side",
+        "DiscussionId": "e2f7677e-0fdd-4ced-9e2e-d0d6e334bb4d",
+        "Mappings": []
+    },
+    {
+        "Path": "speed-test.markdown",
+        "Name": "Client Speed Test",
+        "DiscussionId": "715a3fc0-888c-4e49-9d2d-f6682cf24d3f",
+        "Mappings": []
+    },
+    {
+        "Path": "health-check.markdown",
+        "Name": "Cluster Node Health Check",
+        "DiscussionId": "e3e9b9f4-5e06-4d9a-a1cf-21b6ab521328",
+        "Mappings": []
+    }
+]

Documentation/5.2/Raven.Documentation.Pages/client-api/cluster/how-client-integrates-with-replication-and-cluster.dotnet.markdown

@@ -1,6 +1,20 @@
-# Cluster: How a Client Integrates with Replication and the Cluster
+# Client Integration with the Cluster
+---
 
-{PANEL:**Failover Behavior**}
+{NOTE: }
+
+* In this page:
+    * [Failover behavior](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#failover-behavior)
+    * [Cluster topology in the client](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#cluster-topology-in-the-client)
+    * [Topology discovery](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#topology-discovery)
+    * [Configuring topology nodes](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#configuring-topology-nodes)
+    * [Write assurance and database groups](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#write-assurance-and-database-groups)
+
+{NOTE/}
+
+---
+
+{PANEL: Failover behavior}
 
 * In RavenDB, the replication is _not_ a bundle and is always enabled if there are two nodes or more in the cluster. 
   This means that the failover mechanism is always turned on by default.  
@@ -9,62 +23,75 @@
   Each time the client needs to do a request to a database, it will choose a node that contains this database from this list to send the request to. 
   If the node is down and the request fails, it will select another node from this list.  
 
-* The choice of which node to select depends on the value of `ReadBalanceBehavior`, which is taken from the current conventions. 
-  For more information about the different values and the node selection process, see [Load balance & Failover Conventions](../../client-api/configuration/load-balance/overview). 
-
-{NOTE Each failure to connect to a node spawns a health check for that node. For more information see [Cluster Node Health Check](health-check)./}
+* The choice of which node to select depends on the `ReadBalanceBehavior` and `LoadBalanceBehavior` configuration values.
+  For more information about the different values and the node selection process, see [Load balancing client requests](../../client-api/configuration/load-balance/overview). 
+
+    {NOTE: }
+    Each failure to connect to a node spawns a health check for that node.  
+    For more information see [Cluster Node Health Check](health-check).
+    {NOTE/}
 
 {PANEL/}
 
-{PANEL:**Cluster Topology In The Client**}
+{PANEL: Cluster topology in the client}
 
 When the client is initialized, it fetches the topologies and populates the nodes list for the load-balancing and failover functionality.
 During the lifetime of a RavenDB Client object, it periodically receives the cluster and the databases topologies from the server.  
 
-The topology is updated with the following logic:
+---
+
+The **topology** is updated with the following logic:
 
 * Each topology has an etag, which is a number
 * Each time the topology has changed, the etag is incremented
 * For each request, the client adds the latest topology etag it has to the header
 * If the current topology etag at the server is higher than the one in the client, the server adds `"Refresh-Topology:true"` to the response header
-* If a client detects the `"Refresh-Topology:true"` header in the response, the client will fetch the updated topology from the server
-  Note: if `ReadBalanceBehavior.FastestNode` is selected, the client will schedule a speed test to determine the fastest node
+* If a client detects the `"Refresh-Topology:true"` header in the response, the client will fetch the updated topology from the server.
+  Note: if `ReadBalanceBehavior.FastestNode` is selected, the client will schedule a speed test to determine the fastest node.
+* In addition, every 5 minutes, the client fetches the current topology from the server if no requests are made within that time frame.
+
+---
 
-The client configuration is handled in a similar way:
+The **client configuration** is handled in a similar way:
 
 * Each client configuration has an etag attached
 * Each time the configuration has changed at the server-side, the server adds `"Refresh-Client-Configuration"` to the response
 * When the client detects the aforementioned header in the response, it schedules fetching the new configuration
+
 {PANEL/}
 
-{PANEL:**Topology Discovery**}
-In RavenDB 4.x, cluster topology has an etag which increments after each topology change.
+{PANEL: Topology discovery}
+
+In RavenDB, the cluster topology has an etag that increments with each topology change.
 
-### How and When the Topology is Updated
+#### How and when the topology is updated:
 
 * The first time any request is sent to RavenDB server, the client fetches cluster topology
-* Each subsequent request happens with a fetched topology etag in the HTTP headers, under the key 'Topology-Etag'
-* If the response contains the 'Refresh-Topology: true' header, then a thread responsible for updating the topology will be spawned
+* Each subsequent request happens with a fetched topology etag in the HTTP headers, under the key `Topology-Etag`
+* If the response contains the `Refresh-Topology: true` header, then a thread responsible for updating the topology will be spawned
 
 {PANEL/}
 
-{PANEL:**Configuring Topology Nodes**}
+{PANEL: Configuring topology nodes}
 
 Listing any node in the initialization of the cluster in the client is enough to be able to properly connect to the specified database. 
 Each node in the cluster contains the full topology of all databases and all nodes that are in the cluster.
-Nevertheless, it is possible to specify multiple node urls at the initialization. But why list multiple the nodes in the cluster, if url of any cluster node will do?
+Nevertheless, it is possible to specify multiple node urls at the initialization. But why list multiple nodes in the cluster, if url of any cluster node will do?
 
-By listing multiple the nodes in the cluster, we can ensure that if a single node is down and we bring a new client up, we'll still be able to get the initial topology. If the cluster sizes are small (three to five nodes), we'll typically list all the nodes in the cluster. But for larger clusters, we'll usually just list enough nodes that having them all go down at once will mean that you have more pressing concerns then a new client coming up.
+By listing multiple nodes in the cluster, we can ensure that if a single node is down and we bring a new client up, we'll still be able to get the initial topology. 
+If the cluster sizes are small (three to five nodes), we'll typically list all the nodes in the cluster. 
+But for larger clusters, we'll usually just list enough nodes that having them all go down at once will mean that you have more pressing concerns then a new client coming up.
 
 {CODE InitializationSample@ClientApi\Cluster\HowClientApiIntegratesWithReplicationAndCluster.cs /}
 
 {PANEL/}
 
-{PANEL:**Write assurance and database groups**}
+{PANEL: Write assurance and database groups}
 
 In RavenDB clusters, the databases are hosted in [database groups](../../glossary/database-group). 
 Since there is a master-master replication configured between database group members, a write to one of the nodes will be replicated to all other instances of the group.
-If there are some writes that are important, it is possible to make the client wait until the transaction data gets replicated to multiple nodes. It is called a 'write assurance', and it is available with the `WaitForReplicationAfterSaveChanges()` method.
+If there are some writes that are important, it is possible to make the client wait until the transaction data gets replicated to multiple nodes. 
+It is called a 'write assurance', and it is available with the `WaitForReplicationAfterSaveChanges()` method.
 
 {CODE WriteAssuranceSample@ClientApi\Cluster\HowClientApiIntegratesWithReplicationAndCluster.cs /}
 

Documentation/5.2/Raven.Documentation.Pages/client-api/cluster/how-client-integrates-with-replication-and-cluster.java.markdown

@@ -1,6 +1,20 @@
-# Cluster: How a Client Integrates with Replication and the Cluster
+# Client Integration with the Cluster
+---
 
-{PANEL:**Failover Behavior**}
+{NOTE: }
+
+* In this page:
+    * [Failover behavior](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#failover-behavior)
+    * [Cluster topology in the client](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#cluster-topology-in-the-client)
+    * [Topology discovery](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#topology-discovery)
+    * [Configuring topology nodes](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#configuring-topology-nodes)
+    * [Write assurance and database groups](../../client-api/cluster/how-client-integrates-with-replication-and-cluster#write-assurance-and-database-groups)
+
+{NOTE/}
+
+---
+
+{PANEL: Failover behavior}
 
 * In RavenDB, the replication is _not_ a bundle and is always enabled if there are two nodes or more in the cluster. 
   This means that the failover mechanism is always turned on by default.  
@@ -9,62 +23,75 @@
   Each time the client needs to do a request to a database, it will choose a node that contains this database from this list to send the request to. 
   If the node is down and the request fails, it will select another node from this list.  
 
-* The choice of which node to select depends on the value of `ReadBalanceBehavior`, which is taken from the current conventions. 
-  For more information about the different values and the node selection process, see [Load balance & Failover Conventions](../../client-api/configuration/load-balance/overview). 
-
-{NOTE Each failure to connect to a node spawns a health check for that node. For more information see [Cluster Node Health Check](health-check)./}
+* The choice of which node to select depends on the `ReadBalanceBehavior` and `LoadBalanceBehavior` configuration values.
+  For more information about the different values and the node selection process, see [Load balancing client requests](../../client-api/configuration/load-balance/overview). 
+
+     {NOTE: }
+     Each failure to connect to a node spawns a health check for that node.  
+     For more information see [Cluster Node Health Check](health-check).
+     {NOTE/}
 
 {PANEL/}
 
-{PANEL:**Cluster Topology In The Client**}
+{PANEL: Cluster topology in the client}
 
 When the client is initialized, it fetches the topologies and populates the nodes list for the load-balancing and failover functionality.
 During the lifetime of a RavenDB Client object, it periodically receives the cluster and the databases topologies from the server.  
 
-The topology is updated with the following logic:
+---
+
+The **topology** is updated with the following logic:
 
 * Each topology has an etag, which is a number
 * Each time the topology has changed, the etag is incremented
 * For each request, the client adds the latest topology etag it has to the header
 * If the current topology etag at the server is higher than the one in the client, the server adds `"Refresh-Topology:true"` to the response header
-* If a client detects the `"Refresh-Topology:true"` header in the response, the client will fetch the updated topology from the server
-  Note: if `ReadBalanceBehavior.FASTEST_NODE` is selected, the client will schedule a speed test to determine the fastest node
+* If a client detects the `"Refresh-Topology:true"` header in the response, the client will fetch the updated topology from the server.
+  Note: if `ReadBalanceBehavior.FASTEST_NODE` is selected, the client will schedule a speed test to determine the fastest node.
+* In addition, every 5 minutes, the client fetches the current topology from the server if no requests are made within that time frame.
+
+---
 
-The client configuration is handled in a similar way:
+The **client configuration** is handled in a similar way:
 
 * Each client configuration has an etag attached
 * Each time the configuration has changed at the server-side, the server adds `"Refresh-Client-Configuration"` to the response
 * When the client detects the aforementioned header in the response, it schedules fetching the new configuration
+
 {PANEL/}
 
-{PANEL:**Topology Discovery**}
-In RavenDB 4.x, cluster topology has an etag which increments after each topology change.
+{PANEL: Topology discovery}
+
+In RavenDB, the cluster topology has an etag that increments with each topology change.
 
-### How and When the Topology is Updated
+#### How and when the topology is updated:
 
 * The first time any request is sent to RavenDB server, the client fetches cluster topology
-* Each subsequent request happens with a fetched topology etag in the HTTP headers, under the key 'Topology-Etag'
-* If the response contains the 'Refresh-Topology: true' header, then a thread responsible for updating the topology will be spawned
+* Each subsequent request happens with a fetched topology etag in the HTTP headers, under the key `Topology-Etag`
+* If the response contains the `Refresh-Topology: true` header, then a thread responsible for updating the topology will be spawned
 
 {PANEL/}
 
-{PANEL:**Configuring Topology Nodes**}
+{PANEL: Configuring topology nodes}
 
 Listing any node in the initialization of the cluster in the client is enough to be able to properly connect to the specified database. 
 Each node in the cluster contains the full topology of all databases and all nodes that are in the cluster.
-Nevertheless, it is possible to specify multiple node urls at the initialization. But why list multiple the nodes in the cluster, if url of any cluster node will do?
+Nevertheless, it is possible to specify multiple node urls at the initialization. But why list multiple nodes in the cluster, if url of any cluster node will do?
 
-By listing multiple the nodes in the cluster, we can ensure that if a single node is down and we bring a new client up, we'll still be able to get the initial topology. If the cluster sizes are small (three to five nodes), we'll typically list all the nodes in the cluster. But for larger clusters, we'll usually just list enough nodes that having them all go down at once will mean that you have more pressing concerns then a new client coming up.
+By listing multiple nodes in the cluster, we can ensure that if a single node is down and we bring a new client up, we'll still be able to get the initial topology. 
+If the cluster sizes are small (three to five nodes), we'll typically list all the nodes in the cluster. 
+But for larger clusters, we'll usually just list enough nodes that having them all go down at once will mean that you have more pressing concerns then a new client coming up.
 
 {CODE:java InitializationSample@ClientApi\Cluster\HowClientApiIntegratesWithReplicationAndCluster.java /}
 
 {PANEL/}
 
-{PANEL:**Write assurance and database groups**}
+{PANEL: Write assurance and database groups}
 
 In RavenDB clusters, the databases are hosted in database groups. 
 Since there is a master-master replication configured between database group members, a write to one of the nodes will be replicated to all other instances of the group.
-If there are some writes that are important, it is possible to make the client wait until the transaction data gets replicated to multiple nodes. It is called a 'write assurance', and it is available with the `WaitForReplicationAfterSaveChanges()` method.
+If there are some writes that are important, it is possible to make the client wait until the transaction data gets replicated to multiple nodes.
+It is called a 'write assurance', and it is available with the `WaitForReplicationAfterSaveChanges()` method.
 
 {CODE:java WriteAssuranceSample@ClientApi\Cluster\HowClientApiIntegratesWithReplicationAndCluster.java /}