From cfd9c71a672425ed081b175b88cd96fe67312acf Mon Sep 17 00:00:00 2001 From: fhanik Date: Wed, 11 Oct 2006 17:16:44 +0000 Subject: [PATCH] Update documentation git-svn-id: https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk@462865 13f79535-47bb-0310-9956-ffa450edef68 --- webapps/docs/config/cluster-membership.xml | 29 +++++----- webapps/docs/config/cluster-receiver.xml | 87 ++++++++++++++++++++++++------ 2 files changed, 87 insertions(+), 29 deletions(-) diff --git a/webapps/docs/config/cluster-membership.xml b/webapps/docs/config/cluster-membership.xml index bedd8c62c..0138301bc 100644 --- a/webapps/docs/config/cluster-membership.xml +++ b/webapps/docs/config/cluster-membership.xml @@ -26,9 +26,9 @@ The default implementation of the cluster group notification is built on top of multicast heartbeats sent using UDP packets to a multicast IP address. Cluster members are grouped together by using the same multicast address/port combination. - Each member sends out a heartbeat with a given interval (mcastFrequency), and this + Each member sends out a heartbeat with a given interval (frequency), and this heartbeat is used for dynamic discovery. - In a similar fashion, if a heartbeat has not been received in a timeframe specified by mcastDropTime + In a similar fashion, if a heartbeat has not been received in a timeframe specified by dropTime ms. a member is considered suspect and the channel and any membership listener will be notified.

@@ -48,31 +48,32 @@ This implementation uses multicast heartbeats for member discovery.

- +

The multicast address that the membership will broadcast its presence and listen for other heartbeats on. The default value is 228.0.0.4 Make sure your network is enabled for multicast traffic.
- The multicast address, in conjunction with the mcastPort is what + The multicast address, in conjunction with the port is what creates a cluster group. To divide up your farm into several different group, or to - split up QA from production, change the mcastPort or the mcastAddr + split up QA from production, change the port or the address +
Previously known as mcastAddr.

- +

The multicast port, the default value is 45564
- The multicast port, in conjunction with the mcastAddr is what + The multicast port, in conjunction with the address is what creates a cluster group. To divide up your farm into several different group, or to - split up QA from production, change the mcastPort or the mcastAddr + split up QA from production, change the port or the address

- +

The frequency in milliseconds in which heartbeats are sent out. The default value is 500 ms.
In most cases the default value is sufficient. Changing this value, simply changes the interval in between heartbeats.

- +

The membership component will time out members and notify the Channel if a member fails to send a heartbeat within a give time. The default value is 3000 ms. This means, that if a heartbeat is not received from a @@ -82,14 +83,14 @@ verify a timeout using a TCP connection when a heartbeat timeout has occurred. This protects against false positives.

- +

Use this attribute if you wish to bind your multicast traffic to a specific network interface. By default, or when this attribute is unset, it tries to bind to 0.0.0.0 and sometimes on multihomed hosts this becomes a problem.

- +

The time-to-live setting for the multicast heartbeats. This setting should be a value between 0 and 255. The default value is VM implementation specific. @@ -101,11 +102,11 @@ The org.apache.catalina.tribes.Member.getDomain() method returns the value specified here.

- +

The sending and receiving of heartbeats is done on a single thread, hence to avoid blocking this thread forever, you can control the SO_TIMEOUT value on this socket.
- If a value smaller or equal to 0 is presented, the code will default this value to mcastFrequency + If a value smaller or equal to 0 is presented, the code will default this value to frequency

diff --git a/webapps/docs/config/cluster-receiver.xml b/webapps/docs/config/cluster-receiver.xml index ee05a3e92..b997a756a 100644 --- a/webapps/docs/config/cluster-receiver.xml +++ b/webapps/docs/config/cluster-receiver.xml @@ -15,32 +15,89 @@
- - - +

+ The receiver component is responsible for receiving cluster messages. + As you might notice through the configuration, is that the receiving of messages + and sending of messages are two different components, this is different from many other + frameworks, but there is a good reason for it, to decouple the logic for how messages are sent from + how messages are received.
+ The receiver is very much like the Tomcat Connector, its the base of the thread pool + for incoming cluster messages. The receiver is straight forward, but all the socket settings + for incoming traffic are managed here. +

+
+

+ The receiver supports both a non blocking, org.apache.catalina.tribes.transport.nio.NioReceiver, and a + blocking, org.apache.catalina.tribes.transport.bio.BioReceiver. It is preferred to use the non blocking receiver + to be able to grow your cluster without running into thread starvation.
+ Using the non blocking receiver allows you to with a very limited thread count to serve a large number of messages. + Usually the rule is to use 1 thread per node in the cluster for small clusters, and then depending on your message frequency + and your hardware, you'll find an optimal number of threads peak out at a certain number. +

+
- - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
- - - -- 2.11.0