This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
     new b75ee12  Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723
b75ee12 is described below

commit b75ee12a4ed6724c21f1a670b5a569ff5e043e52
Author: Christopher Schultz <ch...@christopherschultz.net>
AuthorDate: Tue Aug 4 16:59:34 2020 -0400

    Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62723
    
    Clarify the effects of some cluster channelSendOptions.
    
    Patch provided by Mitch Claborn.
---
 webapps/docs/changelog.xml      |  4 ++++
 webapps/docs/cluster-howto.xml  |  2 ++
 webapps/docs/config/cluster.xml | 34 ++++++++++++++++++++++++++++++++++
 3 files changed, 40 insertions(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 95ddadf..1806b15 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,10 @@
         Clean-up / standardize the XSL files used to generate the 
documentation.
         PR provided by John Bampton. (markt)
       </fix>
+      <fix>
+        <bug>62723</bug>: Clarify the effects of some options for cluster
+        <code>channelSendOptions</code>. Patch provided by Mitch Claborn.
+        (schultz)
     </changelog>
   </subsection>
   <subsection name="Other">
diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml
index cfbfc2f..09cdb2c 100644
--- a/webapps/docs/cluster-howto.xml
+++ b/webapps/docs/cluster-howto.xml
@@ -218,6 +218,8 @@ should be completed:</p>
     Synchronous vs. asynchronous is configured using the 
<code>channelSendOptions</code>
     flag and is an integer value. The default value for the 
<code>SimpleTcpCluster/DeltaManager</code> combo is
     8, which is asynchronous.
+    See the <a 
href="config/cluster.html#SimpleTcpCluster_Attributes">configuration 
reference</a>
+    for more discussion on the various <code>channelSendOptions</code> values.
 </p>
 <p>
     For convenience, <code>channelSendOptions</code> can be set by name(s) 
rather than integer,
diff --git a/webapps/docs/config/cluster.xml b/webapps/docs/config/cluster.xml
index 91e8328..12434a8 100644
--- a/webapps/docs/config/cluster.xml
+++ b/webapps/docs/config/cluster.xml
@@ -146,6 +146,40 @@ Tomcat cluster. These include:</p>
       to the order in which they were sent.
       </p>
       <p>
+        The various <code>channelSendOptions</code> values offer a tradeoff
+        between throughput on the sending node and the reliability of
+        replication should the sending or receiving node(s) fail. Here are
+        some common options. "Message" could be any message sent between nodes,
+        but only session-change messages are considered, here.
+      </p>
+      <p>
+        <code>channelSendOptions="8"</code> / 
<code>channelSendOptions="async"</code>
+        As far as the sender is concerned, the message is "sent"
+        as soon as it has been placed in the queue on the sender for
+        transmission to the other nodes. The message may not reach any or all
+        of the recipient nodes and may not be successfully processed on any
+        nodes that it does reach. This option offers the highest throughput on
+        the sender but the least reliability, as the triggering request will
+        complete without any knowledge of the success/failure of the session
+        replication.
+      </p>
+      <p>
+        <code>channelSendOptions="2"</code> / 
<code>channelSendOptions="use_ack"</code>
+        The sender will block the completion of the current request until all
+        of the receiving nodes have acknowledged that they have received the
+        message, but have not necessarily processed that message. This option
+        will result in lower throughput on the sending node, because the 
message
+        must be transmitted and the acknowledgement received, but the
+        reliability is greater than the asynchronous model.
+      </p>
+      <p>
+        <code>channelSendOptions="6"</code> / 
<code>channelSendOptions="sync,use_ack"</code>
+        The sender will block the completion of the current request until
+        all of the receiving nodes have acknowledged that they have received
+        <u>and</u> processed the message. This option will have the lowest
+        throughput (of these three) but the greatest reliability.
+      </p>
+      <p>
       You may also set these options as a comma separated string, e.g. "async, 
multicast", which
       will be translated into <code>Channel.SEND_OPTIONS_ASYNCHRONOUS | 
Channel.SEND_OPTIONS_MULTICAST</code>
       <br/>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to