tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kkoli...@apache.org
Subject svn commit: r1200127 - in /tomcat/tc7.0.x/trunk/webapps/docs: config/ tribes/
Date Thu, 10 Nov 2011 04:08:49 GMT
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=&quot;staging-cluster&quot;
                   uniqueId=&quot;{0,1,2,3,4,5,6,7,8,9}&quot;/&gt;
      &lt;/Interceptor&gt;
-   
+
    </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 &quot;staging-domain&quot; or &quot;tomcat-cluster&quot;
will be converted into bytes 
+       1. Regular string values like &quot;staging-domain&quot; or &quot;tomcat-cluster&quot;
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 &quot;staging-domain&quot; or &quot;tomcat-cluster&quot;
will be converted into bytes 
+       1. Regular string values like &quot;staging-domain&quot; or &quot;tomcat-cluster&quot;
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>&lt;Manager&gt;</code> inside the <code>&lt;Context&gt;</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 &lt;= bindPort &lt;= 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 &quot;Concurrent Parallel Delivery&quot;.

+  Apache Tribes implements what we like to call &quot;Concurrent Parallel Delivery&quot;.
   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
   &quot;Concurrent Parallel Delivery&quot;.
   </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>&lt;Host&gt;</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>&lt;Cluster&gt;</code>
inside the <code>&lt;Engine&gt;</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 &quot;Tribes&quot;
     <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.&lt;property&gt;=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 &lt;Channel&gt; 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


Mime
View raw message