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: [email protected]
For additional commands, e-mail: [email protected]
