View | Details | Raw Unified | Return to bug 62723
Collapse All | Expand All

(-)a/webapps/docs/cluster-howto.xml (+1 lines)
Lines 210-215 should be completed:</p> Link Here
210
    Synchronous vs. asynchronous is configured using the <code>channelSendOptions</code>
210
    Synchronous vs. asynchronous is configured using the <code>channelSendOptions</code>
211
    flag and is an integer value. The default value for the <code>SimpleTcpCluster/DeltaManager</code> combo is
211
    flag and is an integer value. The default value for the <code>SimpleTcpCluster/DeltaManager</code> combo is
212
    8, which is asynchronous.
212
    8, which is asynchronous.
213
    See the <a href="config/cluster.html#SimpleTcpCluster_Attributes">configuration reference</a> for more discussion on the various <code>channelSendOptions</code> values. 
213
</p>
214
</p>
214
<p>
215
<p>
215
    For convenience, <code>channelSendOptions</code> can be set by name(s) rather than integer,
216
    For convenience, <code>channelSendOptions</code> can be set by name(s) rather than integer,
(-)a/webapps/docs/config/cluster.xml (+27 lines)
Lines 145-150 Tomcat cluster. These include:</p> Link Here
145
      to the order in which they were sent.
145
      to the order in which they were sent.
146
      </p>
146
      </p>
147
      <p>
147
      <p>
148
      	The various <code>channelSendOptions</code> values offer a tradeoff between throughput on the sending
149
      	node and the reliability of replication should the sending node fail. Here are some common options. In this discussion
150
      	"message" could be any message sent between the nodes, but in the context of this dicussion it applies to session changes
151
      	being replicated to other nodes.
152
      	<br/> 
153
      	<code>channelSendOptions="8"</code>
154
      	As far as the sender is concerned, the message is sent
155
				as soon as it has been placed in the queue on the sender for
156
				transmission to the other nodes. The message may not reach all of the 
157
				recipient nodes and may not be successfully processed on those nodes that it does reach. 
158
				This option offers the most throughput on the sender but the least reliability, as the 
159
				triggering request will complete without any knowledge of the success/failure of the session replication.
160
      	<br/>
161
      	<code>channelSendOptions="2"</code>
162
      	The sender will block the completion of the current request until all of the receiving nodes 
163
      	have acknowledged that they have received the message, but have not necessarily processed
164
      	that message. 
165
      	This option will result in less throughput on the sending node, because the message must be transmitted
166
      	and the acknowledgement received, but the reliability is greater than the asynchronous model. 
167
      	<br/>
168
      	<code>channelSendOptions="6"</code>
169
      	The sender will block the completion of the current request until
170
				all of the receiving nodes have acknowledged that they have received <u>and</u>
171
				processed the message.
172
				This option will have the least throughput (of these three) but the greatest reliability.
173
      </p>
174
      <p>
148
      You may also set these options as a comma separated string, e.g. "async, multicast", which
175
      You may also set these options as a comma separated string, e.g. "async, multicast", which
149
      will be translated into <code>Channel.SEND_OPTIONS_ASYNCHRONOUS | Channel.SEND_OPTIONS_MULTICAST</code>
176
      will be translated into <code>Channel.SEND_OPTIONS_ASYNCHRONOUS | Channel.SEND_OPTIONS_MULTICAST</code>
150
      <br/>
177
      <br/>

Return to bug 62723