You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by kk...@apache.org on 2011/11/10 05:08:49 UTC
svn commit: r1200127 - in /tomcat/tc7.0.x/trunk/webapps/docs: config/ tribes/
Author: kkolinko
Date: Thu Nov 10 04:08:49 2011
New Revision: 1200127
URL: http://svn.apache.org/viewvc?rev=1200127&view=rev
Log:
Merging r1187809 - Trailing whitespace removal from /webapps
/webapps/docs, 3
Modified:
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-channel.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-deployer.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-interceptor.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-listener.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-manager.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-membership.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-receiver.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-sender.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-valve.xml
tomcat/tc7.0.x/trunk/webapps/docs/config/cluster.xml
tomcat/tc7.0.x/trunk/webapps/docs/tribes/introduction.xml
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-channel.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-channel.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-channel.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-channel.xml Thu Nov 10 04:08:49 2011
@@ -39,7 +39,7 @@
This framework is then used internally by the components that need to send messages between different Tomcat instances.
<br/>
A few examples of these components would be the SimpleTcpCluster that does the messaging for the DeltaManager,
- or the BackupManager that uses a different replication strategy. The ReplicatedContext object does also
+ or the BackupManager that uses a different replication strategy. The ReplicatedContext object does also
use the channel object to communicate context attribute changes.
</section>
<section name="Nested Components">
@@ -47,12 +47,12 @@
The Membership component is responsible for auto discovering new nodes in the cluster
and also to provide for notifications for any nodes that have not responded with a heartbeat.
The default implementation uses multicast.<br/>
- In the membership component you configure how your nodes, aka. members, are to be discovered and/or
- divided up.
+ In the membership component you configure how your nodes, aka. members, are to be discovered and/or
+ divided up.
You can always find out more about <a href="../tribes/introduction.html">Apache Tribes</a>
</p>
<p><b><a href="cluster-sender.html">Channel/Sender</a>:</b> <br/>
- The Sender component manages all outbound connections and data messages that are sent
+ The Sender component manages all outbound connections and data messages that are sent
over the network from one node to another.
This component allows messages to be sent in parallel.
The default implementation uses TCP client sockets, and socket tuning for outgoing messages are
@@ -72,7 +72,7 @@
You can always find out more about <a href="../tribes/introduction.html">Apache Tribes</a>
</p>
<p><b><a href="cluster-interceptor.html">Channel/Interceptor</a>:</b> <br/>
- The channel will send messages through an interceptor stack. Because of this, you have the ability to
+ The channel will send messages through an interceptor stack. Because of this, you have the ability to
customize the way messages are sent and received, and even how membership is handled.<br/>
You can always find out more about <a href="../tribes/introduction.html">Apache Tribes</a>
</p>
@@ -84,7 +84,7 @@
<subsection name="Common Attributes">
<attributes>
-
+
<attribute name="className" required="true">
The default value here is <code>org.apache.catalina.tribes.group.GroupChannel</code> and is
currently the only implementation available.
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-deployer.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-deployer.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-deployer.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-deployer.xml Thu Nov 10 04:08:49 2011
@@ -35,7 +35,7 @@
<section name="Introduction">
<p>TODO - Complete documentation</p>
-
+
</section>
@@ -45,7 +45,7 @@
<subsection name="Common Attributes">
<attributes>
-
+
<attribute name="className" required="true">
</attribute>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-interceptor.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-interceptor.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-interceptor.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-interceptor.xml Thu Nov 10 04:08:49 2011
@@ -76,7 +76,7 @@
domain="staging-cluster"
uniqueId="{0,1,2,3,4,5,6,7,8,9}"/>
</Interceptor>
-
+
</source>
</p>
</section>
@@ -86,7 +86,7 @@
<subsection name="Common Attributes">
<attributes>
<attribute name="className" required="true">
- Required, as there is no default
+ Required, as there is no default
</attribute>
<attribute name="optionFlag" required="false">
If you want the interceptor to trigger on certain message depending on the message's option flag,
@@ -101,7 +101,7 @@
<attribute name="domain" required="true">
The logical cluster domain that this Interceptor accepts.
Two different type of values are possible:<br/>
- 1. Regular string values like "staging-domain" or "tomcat-cluster" will be converted into bytes
+ 1. Regular string values like "staging-domain" or "tomcat-cluster" will be converted into bytes
using ISO-8859-1 encoding.<br/>
2. byte array in string form, for example {216,123,12,3}<br/>
</attribute>
@@ -110,7 +110,7 @@
<subsection name="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor Attributes">
<attributes>
<attribute name="className" required="true">
- Required, This dispatcher uses JDK 1.5 java.util.concurrent package
+ Required, This dispatcher uses JDK 1.5 java.util.concurrent package
</attribute>
<attribute name="optionFlag" required="false">
The default and hard coded value is <code>8 (org.apache.catalina.tribes.Channel.SEND_OPTIONS_ASYNCHRONOUS)</code>.
@@ -130,12 +130,12 @@
</attribute>
<attribute name="alwaysSend" required="false">
What behavior should be executed when the dispatch queue is full. If <code>true</code> (default), then the message is
- is sent synchronously, if <code>false</code> an error is thrown.
+ is sent synchronously, if <code>false</code> an error is thrown.
</attribute>
<attribute name="maxQueueSize" required="false">
Size in bytes of the dispatch queue, the default value is <code> 1024*1024*64 (64MB)</code> sets the maximum queue size for the dispatch queue
if the queue fills up, one can trigger the behavior, if <code>alwaysSend</code> is set to true, the message will be sent synchronously
- if the flag is false, an error is thrown
+ if the flag is false, an error is thrown
</attribute>
</attributes>
</subsection>
@@ -153,7 +153,7 @@
</attribute>
</attributes>
</subsection>
-
+
<subsection name="Nested element StaticMember Attributes">
<attributes>
<attribute name="className" required="true">
@@ -176,7 +176,7 @@
<attribute name="domain" required="true">
The logical cluster domain for this this static member listens for cluster messages.
Two different type of values are possible:<br/>
- 1. Regular string values like "staging-domain" or "tomcat-cluster" will be converted into bytes
+ 1. Regular string values like "staging-domain" or "tomcat-cluster" will be converted into bytes
using ISO-8859-1 encoding.
2. byte array in string form, for example {216,123,12,3}<br/>
</attribute>
@@ -188,7 +188,7 @@
</attributes>
</subsection>
<!--TODO Document all the interceptors-->
-
+
</section>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-listener.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-listener.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-listener.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-listener.xml Thu Nov 10 04:08:49 2011
@@ -35,14 +35,14 @@
<section name="Introduction">
<p>
- The <code>org.apache.catalina.ha.ClusterListener</code> base class
+ The <code>org.apache.catalina.ha.ClusterListener</code> base class
lets you listen in on messages that are received by the <code>Cluster</code> component.
- </p>
+ </p>
</section>
<section name="org.apache.catalina.ha.session.ClusterSessionListener">
<p>
- When using the DeltaManager, the messages are received by the Cluster object and are propagated to the
+ When using the DeltaManager, the messages are received by the Cluster object and are propagated to the
to the manager through this listener.
</p>
</section>
@@ -60,7 +60,7 @@
<subsection name="Common Attributes">
<attributes>
-
+
<attribute name="className" required="true">
</attribute>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-manager.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-manager.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-manager.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-manager.xml Thu Nov 10 04:08:49 2011
@@ -34,7 +34,7 @@
</section>
<section name="Introduction">
- <p>A cluster manager is an extension to Tomcat's session manager interface,
+ <p>A cluster manager is an extension to Tomcat's session manager interface,
<code>org.apache.catalina.Manager</code>.
A cluster manager must implement the
<code>org.apache.catalina.ha.ClusterManager</code> and is solely responsible
@@ -59,7 +59,7 @@
implementation on a per web application basis, by putting the
<code><Manager></code> inside the <code><Context></code> element
either in the <code><a href="context.html">context.xml</a></code> file or the
- <code><a href="index.html">server.xml</a></code> file.</p>
+ <code><a href="index.html">server.xml</a></code> file.</p>
</section>
<section name="Attributes">
@@ -93,7 +93,7 @@
<code>sessionHistory</code>.
</attribute>
</attributes>
- </subsection>
+ </subsection>
<subsection name="org.apache.catalina.ha.session.DeltaManager Attributes">
<attributes>
<attribute name="expireSessionsOnShutdown" required="false">
@@ -142,7 +142,7 @@
considered active sessions.
</attribute>
<attribute name="rpcTimeout" required="false">
- Timeout for RPC message used for broadcast and transfer state from
+ Timeout for RPC message used for broadcast and transfer state from
another map.
Default value is <code>15000</code> milliseconds.
</attribute>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-membership.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-membership.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-membership.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-membership.xml Thu Nov 10 04:08:49 2011
@@ -59,7 +59,7 @@
<subsection name="Multicast Attributes">
<attributes>
-
+
<attribute name="className" required="true">
<p>
The default value is <code>org.apache.catalina.tribes.membership.McastService</code>
@@ -72,8 +72,8 @@
The multicast address that the membership will broadcast its presence and listen
for other heartbeats on. The default value is <code>228.0.0.4</code>
Make sure your network is enabled for multicast traffic.<br/>
- The multicast address, in conjunction with the <code>port</code> is what
- creates a cluster group. To divide up your farm into several different group, or to
+ The multicast address, in conjunction with the <code>port</code> is what
+ creates a cluster group. To divide up your farm into several different group, or to
split up QA from production, change the <code>port</code> or the <code>address</code>
<br/>Previously known as mcastAddr.
</p>
@@ -81,8 +81,8 @@
<attribute name="port" required="false">
<p>
The multicast port, the default value is <code>45564</code><br/>
- The multicast port, in conjunction with the <code>address</code> is what
- creates a cluster group. To divide up your farm into several different group, or to
+ The multicast port, in conjunction with the <code>address</code> is what
+ creates a cluster group. To divide up your farm into several different group, or to
split up QA from production, change the <code>port</code> or the <code>address</code>
</p>
</attribute>
@@ -94,8 +94,8 @@
</attribute>
<attribute name="dropTime" required="false">
<p>
- 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 <code>3000</code> ms. This means, that if a heartbeat is not received from a
+ 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 <code>3000</code> ms. This means, that if a heartbeat is not received from a
member in that timeframe, the membership component will notify the cluster of this.<br/>
On a high latency network you may wish to increase this value, to protect against false positives.<br/>
Apache Tribes also provides a <a href="cluster-interceptor.html#tcpfailuredetector"><code>TcpFailureDetector</code></a> that will
@@ -151,7 +151,7 @@
The default is <code>5000</code> (5 seconds). <br/>
</p>
</attribute>
-
+
<attribute name="localLoopbackDisabled" required="false">
<p>
Membership uses multicast, it will call <code>java.net.MulticastSocket.setLoopbackMode(localLoopbackDisabled)</code>.
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-receiver.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-receiver.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-receiver.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-receiver.xml Thu Nov 10 04:08:49 2011
@@ -37,7 +37,7 @@
<p>
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
+ 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.<br/>
The receiver is very much like the Tomcat Connector, its the base of the thread pool
@@ -48,7 +48,7 @@
<section name="Blocking vs Non-Blocking Receiver">
<p>
- The receiver supports both a non blocking, <code>org.apache.catalina.tribes.transport.nio.NioReceiver</code>, and a
+ The receiver supports both a non blocking, <code>org.apache.catalina.tribes.transport.nio.NioReceiver</code>, and a
blocking, <code>org.apache.catalina.tribes.transport.bio.BioReceiver</code>. It is preferred to use the non blocking receiver
to be able to grow your cluster without running into thread starvation.<br/>
Using the non blocking receiver allows you to with a very limited thread count to serve a large number of messages.
@@ -62,9 +62,9 @@
<attributes>
<attribute name="className" required="true">
The implementation of the receiver component. Two implementations available,
- <code>org.apache.catalina.tribes.transport.nio.NioReceiver</code> and
+ <code>org.apache.catalina.tribes.transport.nio.NioReceiver</code> and
<code>org.apache.catalina.tribes.transport.bio.BioReceiver</code>.<br/>
- The <code>org.apache.catalina.tribes.transport.nio.NioReceiver</code> is the
+ The <code>org.apache.catalina.tribes.transport.nio.NioReceiver</code> is the
preferred implementation
</attribute>
<attribute name="address" required="false">
@@ -73,20 +73,20 @@
<code>java.net.InetAddress.getLocalHost().getHostAddress()</code>.
</attribute>
<attribute name="direct" required="false">
- Possible values are <code>true</code> or <code>false</code>.
+ Possible values are <code>true</code> or <code>false</code>.
Set to true if you want the receiver to use direct bytebuffers when reading data
from the sockets.
</attribute>
<attribute name="port" required="false">
The listen port for incoming data. The default value is <code>4000</code>.
- To avoid port conflicts the receiver will automatically bind to a free port within the range of
+ To avoid port conflicts the receiver will automatically bind to a free port within the range of
<code> port <= bindPort <= port+autoBind</code>
- So for example, if port is 4000, and autoBind is set to 10, then the receiver will open up
+ So for example, if port is 4000, and autoBind is set to 10, then the receiver will open up
a server socket on the first available port in the range 4000-4100.
</attribute>
<attribute name="autoBind" required="false">
Default value is <code>100</code>.
- Use this value if you wish to automatically avoid port conflicts the cluster receiver will try to open a
+ Use this value if you wish to automatically avoid port conflicts the cluster receiver will try to open a
server socket on the <code>port</code> attribute port, and then work up <code>autoBind</code> number of times.
</attribute>
<attribute name="securePort" required="false">
@@ -104,8 +104,8 @@
</attribute>
<attribute name="maxThreads" required="false">
The maximum number of threads in the receiver thread pool. The default value is <code>6</code>
- Adjust this value relative to the number of nodes in the cluster, the number of messages being exchanged and
- the hardware you are running on. A higher value doesn't mean more efficiency, tune this value according to your
+ Adjust this value relative to the number of nodes in the cluster, the number of messages being exchanged and
+ the hardware you are running on. A higher value doesn't mean more efficiency, tune this value according to your
own test results.
</attribute>
<attribute name="minThreads" required="false">
@@ -132,11 +132,11 @@
Boolean value for the socket SO_KEEPALIVE option. Possible values are <code>true</code> or <code>false</code>.
</attribute>
<attribute name="soLingerOn" required="false">
- Boolean value to determine whether to use the SO_LINGER socket option.
+ Boolean value to determine whether to use the SO_LINGER socket option.
Possible values are <code>true</code> or <code>false</code>. Default value is <code>true</code>.
</attribute>
<attribute name="soLingerTime" required="false">
- Sets the SO_LINGER socket option time value. The value is in seconds.
+ Sets the SO_LINGER socket option time value. The value is in seconds.
The default value is <code>3</code> seconds.
</attribute>
<attribute name="soReuseAddress" required="false">
@@ -152,12 +152,12 @@
The default value is <code>true</code>
</attribute>
<attribute name="timeout" required="false">
- Sets the SO_TIMEOUT option on the socket. The value is in milliseconds and the default value is <code>3000</code>
+ Sets the SO_TIMEOUT option on the socket. The value is in milliseconds and the default value is <code>3000</code>
milliseconds.
</attribute>
<attribute name="useBufferPool" required="false">
Boolean value whether to use a shared buffer pool of cached <code>org.apache.catalina.tribes.io.XByteBuffer</code>
- objects. If set to true, the XByteBuffer that is used to pass a message up the channel, will be recycled at the end
+ objects. If set to true, the XByteBuffer that is used to pass a message up the channel, will be recycled at the end
of the requests. This means that interceptors in the channel must not maintain a reference to the object
after the <code>org.apache.catalina.tribes.ChannelInterceptor#messageReceived</code> method has exited.
</attribute>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-sender.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-sender.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-sender.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-sender.xml Thu Nov 10 04:08:49 2011
@@ -45,15 +45,15 @@
<section name="Concurrent Parallel Delivery">
<p>
In the default <code>transport</code> implementation, <code>org.apache.catalina.tribes.transport.nio.PooledParallelSender</code>,
- Apache Tribes implements what we like to call "Concurrent Parallel Delivery".
+ Apache Tribes implements what we like to call "Concurrent Parallel Delivery".
This means that we can send a message to more than one destination at the same time(parallel), and
- deliver two messages to the same destination at the same time(concurrent). Combine these two and we have
+ deliver two messages to the same destination at the same time(concurrent). Combine these two and we have
"Concurrent Parallel Delivery".
</p>
<p>
When is this useful? The simplest example we can think of is when part of your code is sending a 10MB message,
like a war file being deployed, and you need to push through a small 10KB message, say a session being replicated,
- you don't have to wait for the 10MB message to finish, as a separate thread will push in the small message
+ you don't have to wait for the 10MB message to finish, as a separate thread will push in the small message
transmission at the same time. Currently there is no interrupt, pause or priority mechanism available, but check back soon.
</p>
</section>
@@ -64,7 +64,7 @@
you would set all the socket options for the outgoing messages. Please see its attributes below.
There are two implementations, in a similar manner to the <a href="cluster-receiver.html">receiver</a>, one is non-blocking
based and the other is built using blocking IO. <br/>
- <code>org.apache.catalina.tribes.transport.bio.PooledMultiSender</code> is the blocking implementation and
+ <code>org.apache.catalina.tribes.transport.bio.PooledMultiSender</code> is the blocking implementation and
<code>org.apache.catalina.tribes.transport.nio.PooledParallelSender</code>.
Parallel delivery is not available for the blocking implementation due to the fact that it is blocking a thread on sending data.
</p>
@@ -102,7 +102,7 @@
Default value is <code>43800</code> bytes.
</attribute>
<attribute name="directBuffer" required="false">
- Possible values are <code>true</code> or <code>false</code>.
+ Possible values are <code>true</code> or <code>false</code>.
Set to true if you want the receiver to use direct bytebuffers when writing data
to the sockets. Default value is <code>false</code>
</attribute>
@@ -115,7 +115,7 @@
The default value is <code>-1</code>, which is unlimited.
</attribute>
<attribute name="timeout" required="false">
- Sets the SO_TIMEOUT option on the socket. The value is in milliseconds and the default value is <code>3000</code>
+ Sets the SO_TIMEOUT option on the socket. The value is in milliseconds and the default value is <code>3000</code>
milliseconds.(3 seconds) This timeout starts when a message send attempt is starting, until the transfer has been completed.
For the NIO sockets, this will mean, that the caller can guarantee that we will not attempt sending the message
longer than this timeout value. For the blocking IO implementation, this translated directly to the soTimeout.<br/>
@@ -123,8 +123,8 @@
</attribute>
<attribute name="maxRetryAttempts" required="false">
How many times do we retry a failed message, that received a IOException at the socket level.
- The default value is <code>1</code>, meaning we will retry a message that has failed once.
- In other words, we will attempt a message send no more than twice. One is the original send, and one is the
+ The default value is <code>1</code>, meaning we will retry a message that has failed once.
+ In other words, we will attempt a message send no more than twice. One is the original send, and one is the
<code>maxRetryAttempts</code>.
</attribute>
<attribute name="ooBInline" required="false">
@@ -134,11 +134,11 @@
Boolean value for the socket SO_KEEPALIVE option. Possible values are <code>true</code> or <code>false</code>.
</attribute>
<attribute name="soLingerOn" required="false">
- Boolean value to determine whether to use the SO_LINGER socket option.
+ Boolean value to determine whether to use the SO_LINGER socket option.
Possible values are <code>true</code> or <code>false</code>. Default value is <code>true</code>.
</attribute>
<attribute name="soLingerTime" required="false">
- Sets the SO_LINGER socket option time value. The value is in seconds.
+ Sets the SO_LINGER socket option time value. The value is in seconds.
The default value is <code>3</code> seconds.
</attribute>
<attribute name="soReuseAddress" required="false">
@@ -169,7 +169,7 @@
The value is based on a per-destination count.
The default value is <code>25</code>
</attribute>
-
+
</attributes>
</subsection>
</section>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-valve.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-valve.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-valve.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster-valve.xml Thu Nov 10 04:08:49 2011
@@ -66,7 +66,7 @@
<attribute name="primaryIndicator" required="false">
Boolean value, so to true, and the replication valve will insert a request attribute with the name
defined by the <code>primaryIndicatorName</code> attribute.
- The value inserted into the request attribute is either <code>Boolean.TRUE</code> or
+ The value inserted into the request attribute is either <code>Boolean.TRUE</code> or
<code>Boolean.FALSE</code>
</attribute>
<attribute name="primaryIndicatorName" required="false">
@@ -83,7 +83,7 @@
</section>
<section name="org.apache.catalina.ha.session.JvmRouteBinderValve">
- In case of a mod_jk failover, the <code>JvmRouteBinderValve</code> will replace the
+ In case of a mod_jk failover, the <code>JvmRouteBinderValve</code> will replace the
<code>jvmWorker</code> attribute in the session Id, to make future requests stick to this
node. If you want failback capability, don't enable this valve, but if you want your failover to stick,
and for mod_jk not to have to keep probing the node that went down, you use this valve.
@@ -96,7 +96,7 @@
Default value is <code>true</code>
Runtime attribute to turn on and off turn over of the session's jvmRoute value.
</attribute>
-
+
</attributes>
</subsection>
</section>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/config/cluster.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/config/cluster.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/config/cluster.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/config/cluster.xml Thu Nov 10 04:08:49 2011
@@ -49,7 +49,7 @@
container or the <code><Host></code> container.<br/>
Placing it in the engine, means that you will support clustering in all virtual hosts of Tomcat,
and share the messaging component. When you place the <code><Cluster></code> inside the <code><Engine></code>
- element, the cluster will append the host name of each session manager to the managers name so that two contexts with
+ element, the cluster will append the host name of each session manager to the managers name so that two contexts with
the same name but sitting inside two different hosts will be distinguishable.
</p>
</section>
@@ -70,7 +70,7 @@
are/could be loosely coupled and don't rely on the <code>SimpleTcpCluster</code> for its data replication.
</p>
<p><b><a href="cluster-channel.html">Channel</a>:</b> <br/>
- The Channel and its sub components are all part of the IO layer
+ The Channel and its sub components are all part of the IO layer
for the cluster group, and is a module in it's own that we have nick named "Tribes"
<br/>
Any configuring and tuning of the network layer, the messaging and the membership logic
@@ -96,7 +96,7 @@
<p>
<b>Deprecated settings:</b> In the previous version of Tomcat you were able to control session
manager settings using manager.<property>=value.
- This has been discontinued, as the way it was written interferes with
+ This has been discontinued, as the way it was written interferes with
the ability to support multiple different manager classes under one cluster implementation,
as the same properties might have the different effect on different managers.
</p>
@@ -112,12 +112,12 @@
</attribute>
<attribute name="channelSendOptions" required="true">
<p>The Tribes channel send options, default is <code>8</code>.<br/>
- This option is used to set the flag that all messages sent through the
+ This option is used to set the flag that all messages sent through the
SimpleTcpCluster uses. The flag decides how the messages are sent, and is a simple logical OR.<br/>
-
+
<source>
- int options= Channel.SEND_OPTIONS_ASYNCHRONOUS |
- Channel.SEND_OPTIONS_SYNCHRONIZED_ACK |
+ int options= Channel.SEND_OPTIONS_ASYNCHRONOUS |
+ Channel.SEND_OPTIONS_SYNCHRONIZED_ACK |
Channel.SEND_OPTIONS_USE_ACK;
</source>
Some of the values are:<br/>
@@ -132,7 +132,7 @@
</attribute>
<attribute name="channelStartOptions" required="false">
<p>Sets the start and stop flags for the <Channel> object used by the cluster.
- The default is <code>Channel.DEFAULT</code> which starts all the channel services, such as
+ The default is <code>Channel.DEFAULT</code> which starts all the channel services, such as
sender, receiver, multicast sender and multicast receiver.
The following flags are available today:
<source>
@@ -147,7 +147,7 @@
<p>Enable this flag don't forget to disable the channel heartbeat thread.
</p>
</attribute>
-
+
<attribute name="doClusterLog" required="false">
<p><b>Deprecated since 6.0.0</b></p>
<p>Possible values are <code>true</code> or <code>false</code><br/>
Modified: tomcat/tc7.0.x/trunk/webapps/docs/tribes/introduction.xml
URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/tribes/introduction.xml?rev=1200127&r1=1200126&r2=1200127&view=diff
==============================================================================
--- tomcat/tc7.0.x/trunk/webapps/docs/tribes/introduction.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/tribes/introduction.xml Thu Nov 10 04:08:49 2011
@@ -151,8 +151,8 @@
<b>Guaranteed Messaging</b><br/>
In the default implementation of Tribes uses TCP or UDP for messaging. TCP already has guaranteed message delivery
and flow control built in. I believe that the performance of Java TCP, will outperform an implementation of
- Java/UDP/flow-control/message guarantee since the logic happens further down the stack. UDP messaging has been added in for
- sending messages over UDP instead of TCP when desired. The same guarantee scenarios as described below are still available
+ Java/UDP/flow-control/message guarantee since the logic happens further down the stack. UDP messaging has been added in for
+ sending messages over UDP instead of TCP when desired. The same guarantee scenarios as described below are still available
over UDP, however, when a UDP message is lost, it's considered failed.<br/>
Tribes supports both non-blocking and blocking IO operations. The recommended setting is to use non blocking
as it promotes better parallelism when sending and receiving messages. The blocking implementation is available
@@ -265,7 +265,7 @@
<section name="Where can I get Tribes">
<p>
- Tribes ships as a module with Tomcat, and is released as part of the Apache Tomcat release.
+ Tribes ships as a module with Tomcat, and is released as part of the Apache Tomcat release.
</p>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org