geode-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dbar...@apache.org
Subject geode git commit: GEODE-1996 Confusing references to "multicast" for locators ports
Date Fri, 05 May 2017 21:46:29 GMT
Repository: geode
Updated Branches:
  refs/heads/develop 149e06d53 -> 9e089c5eb


GEODE-1996 Confusing references to "multicast" for locators ports


Project: http://git-wip-us.apache.org/repos/asf/geode/repo
Commit: http://git-wip-us.apache.org/repos/asf/geode/commit/9e089c5e
Tree: http://git-wip-us.apache.org/repos/asf/geode/tree/9e089c5e
Diff: http://git-wip-us.apache.org/repos/asf/geode/diff/9e089c5e

Branch: refs/heads/develop
Commit: 9e089c5ebbb14c989b370d20f47ca4f5c69a9c00
Parents: 149e06d
Author: Dave Barnes <dbarnes@pivotal.io>
Authored: Tue May 2 17:04:04 2017 -0700
Committer: Dave Barnes <dbarnes@pivotal.io>
Committed: Fri May 5 14:46:01 2017 -0700

----------------------------------------------------------------------
 ...uted_system_member_configuration.html.md.erb |  8 +++++-
 .../running/firewalls_ports.html.md.erb         |  4 +--
 ...unication_runtime_considerations.html.md.erb | 16 +++++++++---
 ...cation_ephemeral_tcp_port_limits.html.md.erb |  9 ++++---
 ...ommunication_have_enough_sockets.html.md.erb | 17 +++++++++----
 ...tion_setting_socket_buffer_sizes.html.md.erb |  4 +--
 ...ion_tcpip_p2p_handshake_timeouts.html.md.erb |  2 +-
 .../sockets_and_gateways.html.md.erb            |  6 ++---
 .../monitor_tune/udp_communication.html.md.erb  | 26 ++++++++++++++------
 .../statistics/statistics_list.html.md.erb      |  2 +-
 .../gfsh/command-pages/connect.html.md.erb      | 16 ++++++------
 11 files changed, 73 insertions(+), 37 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb
b/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb
index a06a8c8..2ed2a8b 100644
--- a/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb
+++ b/geode-docs/basic_config/config_concepts/distributed_system_member_configuration.html.md.erb
@@ -46,6 +46,12 @@ Every Geode process is a member of a distributed system, even if the distributed
 
 The multi-site topology uses relationships that you configure between members of multiple
distributed systems. Through this configuration, you loosely couple two or more distributed
systems for automated data distribution. This is usually done for sites at geographically
separate locations. You configure a subset of peers in each distributed system site with gateway
senders and/or gateway receivers to manage events that are distributed between the sites.
 
-In the context of a single distributed system, unless otherwise specified, remote members
refers to other members of the same distributed system. In client/server and multi-site installations,
remote generally refers to members in other distributed systems. For example, all servers
are remote to the clients that connect to them. Each client runs standalone, with connections
only to the server tier, so all servers and their other clients are remote to the individual
client. All gateway receivers are remote to the gateway senders that connect to them from
other distributed systems,and to those gateway senders’ peers.
+In the context of a single distributed system, unless otherwise specified, "remote member"
refers to
+another member of the same distributed system. In client/server and multi-site installations,
"remote"
+generally refers to members in other distributed systems. For example, all servers are "remote"
to the
+clients that connect to them. Each client runs standalone, with connections only to the server
tier,
+so all servers and their other clients are "remote" to the individual client. All gateway
receivers
+are "remote" to the gateway senders that connect to them from other distributed systems,
and to those
+gateway senders' peers.
 
 

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/configuring/running/firewalls_ports.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/configuring/running/firewalls_ports.html.md.erb b/geode-docs/configuring/running/firewalls_ports.html.md.erb
index 11e4554..f9787ec 100644
--- a/geode-docs/configuring/running/firewalls_ports.html.md.erb
+++ b/geode-docs/configuring/running/firewalls_ports.html.md.erb
@@ -30,7 +30,7 @@ There are several different port settings that need to be considered when
using
 
 -   Locator port. Geode clients can use the locator to automatically discover cache servers.
The locator port is configurable as a command-line option to the `gfsh start locator` command.
Locators are used in the peer-to-peer cache deployments to discover other processes. They
can be used by clients to locate servers as an alternative to configuring clients with a collection
of server addresses and ports.
 
-    By default, if not otherwise specified, Geode locators use the default multicast port
**10334**.
+    By default, if not otherwise specified, Geode locators use the default port **10334**.
 
 -   Since locators start up the distributed system, locators must also have their ephemeral
port range and TCP port accessible to other members through the firewall.
 -   For clients, you configure the client to connect to servers using the client's pool configuration.
The client's pool configuration has two options: you can create a pool with either a list
of server elements or a list of locator elements. For each element, you specify the host and
port. The ports specified must be made accessible through your firewall.
@@ -151,7 +151,7 @@ This table contains properties potentially involved in firewall behavior,
with a
 <tr class="odd">
 <td><p>Locator</p></td>
 <td><code class="ph codeph">start-locator</code> (for embedded locators)
or <code class="ph codeph">--port</code> parameter to the <code class="ph codeph">gfsh
start locator</code> command.</td>
-<td><em>if not specified upon startup or in the start-locator property, uses
default multicast port 10334</em></td>
+<td><em>if not specified upon startup or in the start-locator property, uses
default port 10334</em></td>
 </tr>
 <tr class="even">
 <td><p>Membership Port Range</p></td>

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb
b/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb
index 77fd42b..2468e47 100644
--- a/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb
+++ b/geode-docs/managing/monitor_tune/multicast_communication_runtime_considerations.html.md.erb
@@ -23,9 +23,17 @@ When you use multicast for messaging and data distribution, you need to
understa
 
 **Multicast Health Monitor**
 
-The Geode management and monitoring system is supplemented by a maxRetransmissionRatio health
monitoring setting for distributed system members. This ratio is the number of retransmission
requests received divided by the number of multicast datagrams written. If the ratio is at
1.0, the member is retransmitting as many packets as it originally sent. Retransmissions are
point-to-point, and many processes may request retransmission, so this number can get quite
high if problems occur. The default value for maxRetransmissionRatio is 0.2.
-
-For example, consider a distributed system with one producer and two consumers of cache events
using multicast to transmit cache updates. The new member is added, which is running on a
machine without multicast enabled. As a result, there is a retransmission request for every
cache update, and the maxRetransmissionRatio changes to 1.0.
+The Geode management and monitoring system is supplemented by a `maxRetransmissionRatio`
health
+monitoring setting for distributed system members. This ratio is the number of retransmission
+requests received divided by the number of multicast datagrams written. If the ratio is at
1.0, the
+member is retransmitting as many packets as it originally sent. Retransmissions are point-to-point,
+and many processes may request retransmission, so this number can get quite high if problems
+occur. The default value for `maxRetransmissionRatio` is 0.2.
+
+For example, consider a distributed system with one producer and two consumers of cache events
using
+multicast to transmit cache updates. The new member is added, which is running on a machine
without
+multicast enabled. As a result, there is a retransmission request for every cache update,
and the
+`maxRetransmissionRatio` changes to 1.0.
 
 **Controlling Memory Use on Geode Hosts with Multicast**
 
@@ -35,7 +43,7 @@ When data is distributed over multicast, Geode incurs a fixed overhead of
memory
 
 Tuning the transmission buffers requires a careful balance. Larger buffers mean that more
data remains available for retransmission, providing more protection in case of a problem.
On the other hand, a larger amount of reserved memory means that less memory is available
for caching.
 
-You can adjust the transmission buffer size by resetting the mcast-send-buffer-size parameter
in the `gemfire.properties` file:
+You can adjust the transmission buffer size by resetting the `mcast-send-buffer-size` parameter
in the `gemfire.properties` file:
 
 ``` pre
 mcast-send-buffer-size=45000

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb
b/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb
index 3df570a..05107a0 100644
--- a/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb
+++ b/geode-docs/managing/monitor_tune/socket_communication_ephemeral_tcp_port_limits.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
 limitations under the License.
 -->
 
-By default, Windows’ ephemeral ports are within the range 1024-4999, inclusive.You can
increase the range.
+By default, Windows’ ephemeral ports are within the range 1024-4999, inclusive. You can
increase the range.
 
 <a id="socket_comm__section_F535D5D99206498DBBD5A6CC3230F25B"></a>
 If you are repeatedly receiving the following exception:
@@ -28,7 +28,7 @@ If you are repeatedly receiving the following exception:
 java.net.BindException: Address already in use: connect
 ```
 
-and if your system is experiencing a high degree of network activity, such as numerous short-lived
client connections, this could be related to a limit on the number of ephemeral TCP ports.
While this issue could occur with other operating systems, typically, it is only seen with
Windows due to a low default limit.
+and if your system is experiencing a high degree of network activity, such as numerous short-lived
client connections, this could be related to a limit on the number of ephemeral TCP ports.
While this issue could occur with other operating systems, typically, it is seen only with
Windows due to a low default limit.
 
 Perform this procedure to increase the limit:
 
@@ -53,6 +53,9 @@ This affects all versions of the Windows operating system.
 
 **Note for UDP on Unix Systems**
 
-Unix systems have a default maximum socket buffer size for receiving UDP multicast and unicast
transmissions that is lower than the default settings for mcast-recv-buffer-size and udp-recv-buffer-size.
To achieve high-volume multicast messaging, you should increase the maximum Unix buffer size
to at least one megabyte.
+Unix systems have a default maximum socket buffer size for receiving UDP multicast and unicast
+transmissions that is lower than the default settings for `mcast-recv-buffer-size` and
+`udp-recv-buffer-size`. To achieve high-volume multicast messaging, you should increase the
maximum
+Unix buffer size to at least one megabyte.
 
 

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb
b/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb
index a075e08..839e9be 100644
--- a/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb
+++ b/geode-docs/managing/monitor_tune/socket_communication_have_enough_sockets.html.md.erb
@@ -27,7 +27,10 @@ Sockets use file descriptors and the operating system’s view of your
applicati
 
 You can configure socket sharing for peer-to-peer and client-to-server connections:
 
--   **Peer-to-peer**. You can configure whether your members share sockets both at the application
level and at the thread level. To enable sharing at the application level, set the `gemfire.properties`
`conserve-sockets` to true. To achieve maximum throughput, however, we recommend that you
set `conserve-sockets` to `false`.
+- **Peer-to-peer**. You can configure whether your members share sockets both at the application
+level and at the thread level. To enable sharing at the application level, set the
+`gemfire.properties` property `conserve-sockets` to `true`. To achieve maximum throughput,
however, we
+recommend that you set `conserve-sockets` to `false`.
 
     At the thread level, developers can override this setting by using the DistributedSystem
API method `setThreadsSocketPolicy`. You might want to enable socket sharing at the application
level and then have threads that do a lot of cache work take sole ownership of their sockets.
Make sure to program these threads to release their sockets as soon as possible using the
`releaseThreadsSockets` method, rather than waiting for a timeout or thread death.
 
@@ -51,7 +54,7 @@ A member’s socket use is governed by a number of factors, including:
 -   Whether it is a server or a client,
 -   How many connections come in from other processes
 
-The socket requirements described here are worst-case. Generally, it is not practical to
calculate exact socket use for your applications. Socket use varies depending a number of
factors including how many members are running, what their threads are doing, and whether
threads share sockets.
+The socket requirements described here are worst-case. Generally, it is not practical to
calculate exact socket use for your applications. Socket use varies depending on a number
of factors including how many members are running, what their threads are doing, and whether
threads share sockets.
 
 To calculate any member’s socket requirements, add up the requirements for every category
that applies to the member. For example, a cache server running in a distributed system with
clients connected to it has both peer-to-peer and server socket requirements.
 
@@ -109,10 +112,14 @@ The threads servicing client requests add to the total count of thread-owned
soc
 
 Servers use one connection for each incoming client connection. By default, each connection
is serviced by a server thread. These threads that service client requests communicate with
the rest of the server distributed system to satisfy the requests and distributed update operations.
Each of these threads uses its own thread-owned sockets for peer-to-peer communication. So
this adds to the server’s group of thread-owned sockets.
 
-The thread and connection count in the server may be limited by server configuration settings.
These are max-connections and max-threads settings in the &lt;cache-server&gt; element
of the `cache.xml`. These settings limit the number of connections the server accepts and
the maximum number of threads that can service client requests. Both of these limit the server's
overall connection requirements:
+The thread and connection count in the server may be limited by server configuration settings.
These
+are `max-connections` and `max-threads` settings in the &lt;cache-server&gt; element
of the
+`cache.xml`. These settings limit the number of connections the server accepts and the maximum
+number of threads that can service client requests. Both of these limit the server's overall
+connection requirements:
 
 -   When the connection limit is reached, the server refuses additional connections. This
limits the number of connections the server uses for clients.
--   When the thread limit is reached, threads start servicing multiple connections. This
does not limit the number of client connections, but does limit the number of peer connections
required to service client requests. Each server thread used for clients uses its own sockets,
so it requires 2 connections to each of the server’s peers. The max-threads setting puts
a cap on the number of this type of peer connection that your server needs.
+-   When the thread limit is reached, threads start servicing multiple connections. This
does not limit the number of client connections, but does limit the number of peer connections
required to service client requests. Each server thread used for clients uses its own sockets,
so it requires 2 connections to each of the server’s peers. The `max-threads` setting puts
a cap on the number of this type of peer connection that your server needs.
 
 The server uses one socket for each incoming client pool connection. If client subscriptions
are used, the server creates an additional connection to each client that enables subscriptions.
 
@@ -139,7 +146,7 @@ In this table, M is the total number of members in the distributed system.
 <td>Number of pool connections to this server</td>
 </tr>
 <tr class="odd">
-<td><p>Threads servicing client requests (the lesser of the client pool connection
count and the server’s max-threads setting). These connections are to the server’s peers.</p></td>
+<td><p>Threads servicing client requests (the lesser of the client pool connection
count and the server’s <code>max-threads</code> setting). These connections
are to the server’s peers.</p></td>
 <td><p>(2 * number of threads in a server that service client pool connections)</p>
 <p>* (M-1)</p>
 <p>These threads do not share sockets.</p></td>

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb
b/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb
index 41884a2..665b98b 100644
--- a/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb
+++ b/geode-docs/managing/monitor_tune/socket_communication_setting_socket_buffer_sizes.html.md.erb
@@ -19,11 +19,11 @@ See the License for the specific language governing permissions and
 limitations under the License.
 -->
 
-When you determine buffer size settings, you try to strike a balance between communication
needs and other processing.
+When you determine buffer size settings, you must strike a balance between communication
needs and other processing.
 
 Larger socket buffers allow your members to distribute data and events more quickly, but
they also take memory away from other things. If you store very large data objects in your
cache, finding the right sizing for your buffers while leaving enough memory for the cached
data can become critical to system performance.
 
-Ideally, you should have buffers large enough for the distribution of any single data object
so you don’t get message fragmentation, which lowers performance. Your buffers should be
at least as large as your largest stored objects and their keys plus some overhead for message
headers. The overhead varies depending on the who is sending and receiving, but 100 bytes
should be sufficient. You can also look at the statistics for the communication between your
processes to see how many bytes are being sent and received.
+Ideally, you should have buffers large enough for the distribution of any single data object
so you don’t get message fragmentation, which lowers performance. Your buffers should be
at least as large as your largest stored objects and their keys plus some overhead for message
headers. The overhead varies depending on who is sending and receiving, but 100 bytes should
be sufficient. You can also look at the statistics for the communication between your processes
to see how many bytes are being sent and received.
 
 If you see performance problems and logging messages indicating blocked writers, increasing
your buffer sizes may help.
 

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb
b/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb
index 486c337..5e43531 100644
--- a/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb
+++ b/geode-docs/managing/monitor_tune/socket_communication_tcpip_p2p_handshake_timeouts.html.md.erb
@@ -19,7 +19,7 @@ See the License for the specific language governing permissions and
 limitations under the License.
 -->
 
-You can alleviate connection handshake timeouts for TCP/IP connections by increasing the
connection handshake timeout interval with the system property p2p.handshakeTimeoutMs.
+You can alleviate connection handshake timeouts for TCP/IP connections by increasing the
connection handshake timeout interval with the system property `p2p.handshakeTimeoutMs`.
 
 The default setting is 59000 milliseconds.
 

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb b/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb
index ca20bf8..1a3c543 100644
--- a/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb
+++ b/geode-docs/managing/monitor_tune/sockets_and_gateways.html.md.erb
@@ -58,7 +58,7 @@ This table lists the settings for gateway relationships and protocols, and
tells
 
 **TCP/IP Buffer Sizes**
 
-If possible, your TCP/IP buffer size settings should match across your GemFire installation.
At a minimum, follow the guidelines listed here.
+If possible, your TCP/IP buffer size settings should match across your installation. At a
minimum, follow the guidelines listed here.
 
 -   **Multisite (WAN)**. In a multi-site installation using gateways, if the link between
sites is not tuned for optimum throughput, it could cause messages to back up in the cache
queues. If a receiving queue overflows because of inadequate buffer sizes, it will become
out of sync with the sender and the receiver will be unaware of the condition.
 
@@ -111,11 +111,11 @@ Each gateway sender and gateway receiver uses a socket to distribute
events or t
 </tbody>
 </table>
 
-Servers are peers in their own distributed system and have the additional socket requirements
as noted in the Peer-to-Peer section above.
+Servers are peers in their own distributed systems and have the additional socket requirements
as noted in the Peer-to-Peer section above.
 
 ## <a id="socket_comm__section_66D11C8E84F941B58800EDB52194B087" class="no-quick-link"></a>Member
produces SocketTimeoutException
 
-A client, server, gateway sender, or gateway receiver produces a SocketTimeoutException when
it stops waiting for a response from the other side of the connection and closes the socket.
This exception typically happens on the handshake or when establishing a callback connection.
+A client, server, gateway sender, or gateway receiver produces a `SocketTimeoutException`
when it stops waiting for a response from the other side of the connection and closes the
socket. This exception typically happens on the handshake or when establishing a callback
connection.
 
 Response:
 

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/managing/monitor_tune/udp_communication.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/managing/monitor_tune/udp_communication.html.md.erb b/geode-docs/managing/monitor_tune/udp_communication.html.md.erb
index 4a5d3c0..a42aa25 100644
--- a/geode-docs/managing/monitor_tune/udp_communication.html.md.erb
+++ b/geode-docs/managing/monitor_tune/udp_communication.html.md.erb
@@ -27,24 +27,34 @@ Before you begin, you should understand Geode [Basic Configuration and
Programmi
 
 ## <a id="udp_comm__section_4089ACC33AF34FA888BAE3CA3602A730" class="no-quick-link"></a>UDP
Datagram Size
 
-You can change the UDP datagram size with the Geode property udp-fragment-size. This is the
maximum packet size for transmission over UDP unicast or multicast sockets. When possible,
smaller messages are combined into batches up to the size of this setting.
+You can change the UDP datagram size with the Geode property `udp-fragment-size`. This is
the maximum packet size for transmission over UDP unicast or multicast sockets. When possible,
smaller messages are combined into batches up to the size of this setting.
 
 Most operating systems set a maximum transmission size of 64k for UDP datagrams, so this
setting should be kept under 60k to allow for communication headers. Setting the fragment
size too high can result in extra network traffic if your network is subject to packet loss,
as more data must be resent for each retransmission. If many UDP retransmissions appear in
DistributionStats, you maybe achieve better throughput by lowering the fragment size.
 
 ## <a id="udp_comm__section_B9882A4EBA004599B2207B9CB1D3ADC9" class="no-quick-link"></a>UDP
Flow Control
 
-UDP protocols typically have a flow control protocol built into them to keep processes from
being overrun by incoming no-ack messages. The Geode UDP flow control protocol is a credit
based system in which the sender has a maximum number of bytes it can send before getting
its byte credit count replenished, or recharged, by its receivers. While its byte credits
are too low, the sender waits. The receivers do their best to anticipate the sender’s recharge
requirements and provide recharges before they are needed. If the senders credits run too
low, it explicitly requests a recharge from its receivers.
+UDP protocols typically have a flow-control protocol built into them to keep processes from
being
+overrun by incoming no-ack messages. The Geode UDP flow-control protocol is a credit based
system in
+which the sender has a maximum number of bytes it can send before getting its byte credit
count
+replenished, or recharged, by its receivers. While its byte credits are too low, the sender
+waits. The receivers do their best to anticipate the sender’s recharge requirements and
provide
+recharges before they are needed. If the sender's credits run too low, it explicitly requests
a
+recharge from its receivers.
 
-This flow control protocol, which is used for all multicast and unicast no-ack messaging,
is configured using a three-part Geode property mcast-flow-control. This property is composed
of:
+This flow-control protocol, which is used for all multicast and unicast no-ack messaging,
is
+configured using a three-part Geode property `mcast-flow-control`. This property is composed
of:
 
--   byteAllowance—Determines how many bytes (also referred to as credits) can be sent before
receiving a recharge from the receiving processes.
--   rechargeThreshold—Sets a lower limit on the ratio of the sender’s remaining credit
to its byteAllowance. When the ratio goes below this limit, the receiver automatically sends
a recharge. This reduces recharge request messaging from the sender and helps keep the sender
from blocking while waiting for recharges.
--   rechargeBlockMs—Tells the sender how long to wait while needing a recharge before explicitly
requesting one.
+-   `byteAllowance`—Determines how many bytes (also referred to as credits) can be sent
before receiving a recharge from the receiving processes.
+-   `rechargeThreshold`—Sets a lower limit on the ratio of the sender’s remaining credit
to its `byteAllowance`. When the ratio goes below this limit, the receiver automatically sends
a recharge. This reduces recharge request messaging from the sender and helps keep the sender
from blocking while waiting for recharges.
+-   `rechargeBlockMs`—Tells the sender how long to wait while needing a recharge before
explicitly requesting one.
 
-In a well-tuned system, where consumers of cache events are keeping up with producers, the
byteAllowance can be set high to limit flow-of-control messaging and pauses. JVM bloat or
frequent message retransmissions are an indication that cache events from producers are overrunning
consumers.
+In a well-tuned system, where consumers of cache events are keeping up with producers, the
`byteAllowance` can be set high to limit flow-of-control messaging and pauses. JVM bloat or
frequent message retransmissions are an indication that cache events from producers are overrunning
consumers.
 
 ## <a id="udp_comm__section_FB1F54A41D2643A29DB416D309ED4C56" class="no-quick-link"></a>UDP
Retransmission Statistics
 
 Geode stores retransmission statistics for its senders and receivers. You can use these statistics
to help determine whether your flow control and fragment size settings are appropriate for
your system.
 
-The retransmission rates are stored in the DistributionStats ucastRetransmits and mcastRetransmits.
For multicast, there is also a receiver-side statistic mcastRetransmitRequests that can be
used to see which processes aren't keeping up and are requesting retransmissions. There is
no comparable way to tell which receivers are having trouble receiving unicast UDP messages.
+The retransmission rates are stored in the DistributionStats `ucastRetransmits` and
+`mcastRetransmits`. For multicast, there is also a receiver-side statistic `mcastRetransmitRequests`
+that can be used to see which processes aren't keeping up and are requesting retransmissions.
There
+is no comparable way to tell which receivers are having trouble receiving unicast UDP messages.

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/reference/statistics/statistics_list.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/reference/statistics/statistics_list.html.md.erb b/geode-docs/reference/statistics/statistics_list.html.md.erb
index 7f7b76f..c38b2f7 100644
--- a/geode-docs/reference/statistics/statistics_list.html.md.erb
+++ b/geode-docs/reference/statistics/statistics_list.html.md.erb
@@ -588,7 +588,7 @@ Statistics regarding operations performed on a disk region for persistence/overf
 
 ## <a id="section_ACB4161F10D64BC0B15871D003FF6FDF" class="no-quick-link"></a>Distributed
System Messaging (DistributionStats)
 
-Statistics on the Geode distribution layer. These statistcs can be used to tell how much
message traffic exists between this member and other distributed system members.
+Statistics on the Geode distribution layer. These statistics can be used to tell how much
message traffic exists between this member and other distributed system members.
 
 The primary statistics are:
 

http://git-wip-us.apache.org/repos/asf/geode/blob/9e089c5e/geode-docs/tools_modules/gfsh/command-pages/connect.html.md.erb
----------------------------------------------------------------------
diff --git a/geode-docs/tools_modules/gfsh/command-pages/connect.html.md.erb b/geode-docs/tools_modules/gfsh/command-pages/connect.html.md.erb
index c83d2ff..7ecb850 100644
--- a/geode-docs/tools_modules/gfsh/command-pages/connect.html.md.erb
+++ b/geode-docs/tools_modules/gfsh/command-pages/connect.html.md.erb
@@ -19,12 +19,14 @@ See the License for the specific language governing permissions and
 limitations under the License.
 -->
 
-Connect to a jmx-manager either directly or via a locator.
+Connect to a JMX manager either directly or via a locator.
 
 <a id="concept_C2DCEE6743304549825C9B62E66DBADF__section_C27BE964CE554180A65968DBEBF50B23"></a>
-If you are connecting via a locator, and a jmx-manager does not already exist, the locator
starts one.
+If you are connecting via a locator, and a JMX manager does not already exist, the locator
starts one.
 
-gfsh connects as a discovery client to the locator service and asks where the JMX Manager
is. The locator knows when there is no member currently configured as the JMX manager and
simply starts up the JMX manager service within itself. gfsh connects as a JMX client to locator
JMX RMI port.
+gfsh connects as a discovery client to the locator service and asks where the JMX Manager
is. The
+locator knows when there is no member currently configured as the JMX manager and simply
starts up
+the JMX manager service within itself. gfsh connects as a JMX client to the locator's JMX
RMI port.
 
 You can also connect to a remote locator using the HTTP protocol, as illustrated by the second
example below.
 
@@ -63,7 +65,7 @@ connect [--locator=value] [--jmx-manager=value] [--use-http(=value)?] [--url=val
 </tr>
 <tr class="even">
 <td><span class="keyword parmname">\-\-jmx-manager </span></td>
-<td>Network address of the jmx-manager in the form: <code class="ph codeph">host[port]</code>.</td>
+<td>Network address of the JMX manager in the form: <code class="ph codeph">host[port]</code>.</td>
 <td> </td>
 </tr>
 <tr class="odd">
@@ -82,7 +84,7 @@ connect [--locator=value] [--jmx-manager=value] [--use-http(=value)?] [--url=val
 <tr class="odd">
 <td><span class="keyword parmname">\-\-user</span></td>
 <td>The user name of the credential to use in authentication when connecting
-to the jmx-manager.
+to the JMX manager.
 When specified, if the <code>--password</code> option is not also specified,
 <code>gfsh</code> will prompt for the password.</td>
 <td> </td>
@@ -90,7 +92,7 @@ When specified, if the <code>--password</code> option is not
also specified,
 <tr class="even">
 <td><span class="keyword parmname">\-\-password</span></td>
 <td>The password portion of the credential to use in authentication 
-when connecting to the jmx-manager.
+when connecting to the JMX manager.
 </td>
 <td> </td>
 </tr>
@@ -144,7 +146,7 @@ when connecting to the jmx-manager.
 
 **Example Commands:**
 
-If you do not specify a locator or jmx-manager, `gfsh` connects to the locator on the localhost
at the default port.
+If you do not specify a locator or JMX manager, `gfsh` connects to the locator on the localhost
at the default port.
 
 ``` pre
 gfsh>connect


Mime
View raw message