[patch] patch for documentation files

clusterdoc.patch (text/plain), 3.03 KB, created by Mitch Claborn on 2018-09-14 19:08:48 UTC

(hide)

Description: patch for documentation files

Filename:

MIME Type:

Creator: Mitch Claborn

Created: 2018-09-14 19:08:48 UTC

Size: 3.03 KB

patch

obsolete

>diff --git a/webapps/docs/cluster-howto.xml b/webapps/docs/cluster-howto.xml >index f789079..b75d098 100644 >--- a/webapps/docs/cluster-howto.xml >+++ b/webapps/docs/cluster-howto.xml >@@ -210,6 +210,7 @@ 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 36bbf0d..6a47eb9 100644 >--- a/webapps/docs/config/cluster.xml >+++ b/webapps/docs/config/cluster.xml >@@ -145,6 +145,33 @@ 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 node fail. Here are some common options. In this discussion >+ "message" could be any message sent between the nodes, but in the context of this dicussion it applies to session changes >+ being replicated to other nodes. >+ <br/> >+ <code>channelSendOptions="8"</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 all of the >+ recipient nodes and may not be successfully processed on those nodes that it does reach. >+ This option offers the most 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. >+ <br/> >+ <code>channelSendOptions="2"</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 less throughput on the sending node, because the message must be transmitted >+ and the acknowledgement received, but the reliability is greater than the asynchronous model. >+ <br/> >+ <code>channelSendOptions="6"</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 least 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/> View Attachment As Diff View Attachment As Raw

This is ASF Bugzilla: the Apache Software Foundation bug system. In case of problems with the functioning of ASF Bugzilla, please contact bugzilla-admin@apache.org. Please Note: this e-mail address is only for reporting problems with ASF Bugzilla. Mail about any other subject will be silently ignored.

• • Home
  • | New
  • | Browse
  • | Search
  • |
    [?]
  • | Reports
  • | Help
  • | New Account
  • | Log In
    Remember [x]
  • | Forgot Password
    Login: [x]