ASF Bugzilla – Attachment 36150 Details for
Bug 62723
Clarify "channelSendOptions" value in cluster documentation
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
Remember
[x]
|
Forgot Password
Login:
[x]
[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/>
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 62723
: 36150