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 <[email protected]> Authored: Tue May 2 17:04:04 2017 -0700 Committer: Dave Barnes <[email protected]> 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 <cache-server> 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 <cache-server> 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
