[jboss-cvs] JBossAS SVN: r94484 - in projects/docs/enterprise/5.0: Administration_And_Configuration_Guide/en-US and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Oct 7 19:20:31 EDT 2009
Author: laubai
Date: 2009-10-07 19:20:31 -0400 (Wed, 07 Oct 2009)
New Revision: 94484
Removed:
projects/docs/enterprise/5.0/bclare/
Modified:
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
Log:
Removed test commit folder bclare.
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2009-10-07 22:57:31 UTC (rev 94483)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2009-10-07 23:20:31 UTC (rev 94484)
@@ -4,16 +4,44 @@
<chapter id="jgroups.chapt">
<title>JGroups Services</title>
<para>JGroups provides the underlying group communication support for
- JBoss Enterprise Application Platform clusters. JBoss Enterprise Application Platform ships with a reasonable set of default JGroups
- configurations. Most applications just work out of the box with the
- default configurations. You only need to tweak them when you are
- deploying an application that has special network or performance requirements.</para>
+ JBoss Enterprise Application Platform clusters. The interaction of clustered
+ services with JGroups was covered in <xref linkend="clustering-blocks-jgroups"/>.
+ This chapter focuses on the details of this interaction, with particular attention
+ to configuration details and troubleshooting tips.
+ </para>
+ <para>
+ This chapter is not intended as complete JGroups documentation. If you want to
+ know more about JGroups, you can consult:
+ </para>
+
+ <itemizedlist>
+ <listitem><para>The JGroups project documentation at <ulink url="http://jgroups.org/ug.html">http://jgroups.org/ug.html</ulink></para></listitem>
+ <listitem><para>The JGroups wiki pages at jboss.org, rooted at <ulink url="https://www.jboss.org/community/wiki/JGroups">https://www.jboss.org/community/wiki/JGroups</ulink></para></listitem>
+ </itemizedlist>
+
+ <para>
+ The first section of this chapter covers the many JGroups
+ configuration options in detail. JBoss Enterprise Application Platform
+ ships with a set of default JGroups configurations. Most applications
+ will work with the default configurations out of the box. You will only
+ need to edit these configurations when you deploy an application with special
+ network or performance requirements.
+ </para>
<section id="jgroups-configuration">
<title>Configuring a JGroups Channel's Protocol Stack</title>
- <para>The JGroups framework provides services to enable peer-to-peer communications between nodes in a
- cluster. It is built on top a stack of network communication protocols that provide transport,
- discovery, reliability and failure detection, and cluster membership management services. <xref linkend="JGroupsStack.fig"/> shows the protocol stack in JGroups.</para>
+ <para>
+ The JGroups framework provides services to enable peer-to-peer communications between nodes in a
+ cluster. Communication occurs over a communication channel. The channel built up from
+ a stack of network communication <emphasis>protocols<emphasis>, each of which is responsible
+ for adding a particular capability to the overall behavior of the channel.
+ Key capabilities provided by various protocols include transport,
+ cluster discovery, message ordering, lossless message delivery, detection
+ of failed peers, and cluster membership management services.</para>
+
+ <para><xref linkend="JGroupsStack.fig"/> shows a conceptual cluster with
+ each member's channel composed of a stack of JGroups protocols.</para>
+
<figure id="JGroupsStack.fig">
<title>Protocol stack in JGroups</title>
<mediaobject>
@@ -22,190 +50,324 @@
</imageobject>
</mediaobject>
</figure>
- <para>JGroups configurations often appear as a nested attribute in cluster related MBean services, such as
- the <literal>PartitionConfig</literal> attribute in the <literal>ClusterPartition</literal> MBean or the
- <literal>ClusterConfig</literal> attribute in the <literal>TreeCache</literal> MBean. You can
- configure the behavior and properties of each protocol in JGroups via those MBean attributes. Below is
- an example JGroups configuration in the <literal>ClusterPartition</literal> MBean.</para>
-<programlisting><![CDATA[
-<mbean code="org.jboss.ha.framework.server.ClusterPartition"
- name="jboss:service=${jboss.partition.name:DefaultPartition}">
-
- ... ...
-
- <attribute name="PartitionConfig">
- <Config>
-
- <UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}"
- mcast_port="${jboss.hapartition.mcast_port:45566}"
- tos="8"
- ucast_recv_buf_size="20000000"
- ucast_send_buf_size="640000"
- mcast_recv_buf_size="25000000"
- mcast_send_buf_size="640000"
- loopback="false"
- discard_incompatible_packets="true"
- enable_bundling="false"
- max_bundle_size="64000"
- max_bundle_timeout="30"
- use_incoming_packet_handler="true"
- use_outgoing_packet_handler="false"
- ip_ttl="${jgroups.udp.ip_ttl:2}"
- down_thread="false" up_thread="false"/>
-
- <PING timeout="2000"
- down_thread="false" up_thread="false" num_initial_members="3"/>
-
- <MERGE2 max_interval="100000"
- down_thread="false" up_thread="false" min_interval="20000"/>
- <FD_SOCK down_thread="false" up_thread="false"/>
-
- <FD timeout="10000" max_tries="5"
- down_thread="false" up_thread="false" shun="true"/>
- <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
- <pbcast.NAKACK max_xmit_size="60000"
- use_mcast_xmit="false" gc_lag="0"
- retransmit_timeout="300,600,1200,2400,4800"
- down_thread="false" up_thread="false"
- discard_delivered_msgs="true"/>
- <UNICAST timeout="300,600,1200,2400,3600"
- down_thread="false" up_thread="false"/>
- <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
- down_thread="false" up_thread="false"
- max_bytes="400000"/>
- <pbcast.GMS print_local_addr="true" join_timeout="3000"
- down_thread="false" up_thread="false"
- join_retry_timeout="2000" shun="true"
- view_bundling="true"/>
- <FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
- <pbcast.STATE_TRANSFER down_thread="false"
- up_thread="false" use_flush="false"/>
- </Config>
- </attribute>
-</mbean> ]]>
+
+ <para>
+ This section of the chapter covers some of the most commonly used protocols,
+ according to the type of behaviour they add to the channel. We discuss a few
+ key configuration attributes exposed by each protocol, but since these attributes
+ should be altered only by experts, this chapter focuses on familiarizing users
+ with the purpose of various protocols.
+ </para>
+
+ <para>The JGroups configurations used in JBoss Enterprise Application Platform
+ appear as nested elements in the
+ <filename>$JBOSS_HOME/server/all/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</filename>
+ file. This file is parsed by the <literal>ChannelFactory</literal> service,
+ which uses the contents to provide correctly configured channels to the clustered services
+ that require them. See <xref linkend="clustering-blocks-jgroups-channelfactory"/>
+ for more on the <literal>ChannelFactory</literal> service.</para>
+
+ <para>The following is an example protocol stack configuration from
+ <filename>jgroups-channelfactory-stacks.xml</filename>:</para>
+<programlisting><![CDATA[<stack name="udp-async"
+ description="Same as the default 'udp' stack above, except message bundling
+ is enabled in the transport protocol (enable_bundling=true).
+ Useful for services that make high-volume asynchronous
+ RPCs (e.g. high volume JBoss Cache instances configured
+ for REPL_ASYNC) where message bundling may improve performance.">
+ <config>
+ <UDP
+ singleton_name="udp-async"
+ mcast_port="${jboss.jgroups.udp_async.mcast_port:45689}"
+ mcast_addr="${jboss.partition.udpGroup:228.11.11.11}"
+ tos="8"
+ ucast_recv_buf_size="20000000"
+ ucast_send_buf_size="640000"
+ mcast_recv_buf_size="25000000"
+ mcast_send_buf_size="640000"
+ loopback="true"
+ discard_incompatible_packets="true"
+ enable_bundling="true"
+ max_bundle_size="64000"
+ max_bundle_timeout="30"
+ ip_ttl="${jgroups.udp.ip_ttl:2}"
+ thread_naming_pattern="cl"
+ timer.num_threads="12"
+ enable_diagnostics="${jboss.jgroups.enable_diagnostics:true}"
+ diagnostics_addr="${jboss.jgroups.diagnostics_addr:224.0.0.75}"
+ diagnostics_port="${jboss.jgroups.diagnostics_port:7500}"
+
+ thread_pool.enabled="true"
+ thread_pool.min_threads="8"
+ thread_pool.max_threads="200"
+ thread_pool.keep_alive_time="5000"
+ thread_pool.queue_enabled="true"
+ thread_pool.queue_max_size="1000"
+ thread_pool.rejection_policy="discard"
+
+ oob_thread_pool.enabled="true"
+ oob_thread_pool.min_threads="8"
+ oob_thread_pool.max_threads="200"
+ oob_thread_pool.keep_alive_time="1000"
+ oob_thread_pool.queue_enabled="false"
+ oob_thread_pool.rejection_policy="discard"/>
+ <PING timeout="2000" num_initial_members="3"/>
+ <MERGE2 max_interval="100000" min_interval="20000"/>
+ <FD_SOCK/>
+ <FD timeout="6000" max_tries="5" shun="true"/>
+ <VERIFY_SUSPECT timeout="1500"/>
+ <BARRIER/>
+ <pbcast.NAKACK use_mcast_xmit="true" gc_lag="0"
+ retransmit_timeout="300,600,1200,2400,4800"
+ discard_delivered_msgs="true"/>
+ <UNICAST timeout="300,600,1200,2400,3600"/>
+ <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
+ max_bytes="400000"/>
+ <VIEW_SYNC avg_send_interval="10000"/>
+ <pbcast.GMS print_local_addr="true" join_timeout="3000"
+ shun="true"
+ view_bundling="true"
+ view_ack_collection_timeout="5000"
+ resume_task_timeout="7500"/>
+ <FC max_credits="2000000" min_threshold="0.10"
+ ignore_synchronous_response="true"/>
+ <FRAG2 frag_size="60000"/>
+ <!-- pbcast.STREAMING_STATE_TRANSFER/ -->
+ <pbcast.STATE_TRANSFER/>
+ <pbcast.FLUSH timeout="0" start_flush_timeout="10000"/>
+ </config>
+ </stack> ]]>
</programlisting>
+
+
+
<para>
- All the JGroups configuration data is contained in the <Config> element under the JGroups config MBean attribute. This information is used to configure a JGroups Channel; the Channel is conceptually similar to a socket, and manages communication between peers in a cluster. Each element inside the <Config> element defines a particular JGroups Protocol; each Protocol performs one function, and the combination of those functions is what defines the characteristics of the overall Channel. In the next several sections, we will dig into the commonly used protocols and their options and explain exactly what they mean.
+ The <literal><config></literal> element contains all the configuration data for JGroups. This
+ information is used to configure a JGroups <emphasis>channel</emphasis>, which is conceptually similar to a socket, and manages communication between peers in a cluster. Each element within the <literal><config></literal> element defines a particular JGroups <emphasis>protocol</emphasis>. Each protocol performs one function. The combination of these functions defines the characteristics of the channel as a whole. The next few sections describe common protocols and explain the options available to each.
</para>
<section><title>Common Configuration Properties</title>
- <para>The following common properties are exposed by all of the JGroups protocols discussed below:
+ <para>The following property is exposed by all of the JGroups protocols discussed below:
</para>
<itemizedlist>
- <listitem>
- <para><literal>down_thread</literal> whether the protocol should create an internal queue and a queue processing thread (aka the down_thread) for messages passed down from higher layers. The higher layer could be another protocol higher in the stack, or the application itself, if the protocol is the top one on the stack. If true (the default), when a message is passed down from a higher layer, the calling thread places the message in the protocol's queue, and then returns immediately. The protocol's down_thread is responsible for reading messages off the queue, doing whatever protocol-specific processing is required, and passing the message on to the next protocol in the stack.
- </para>
- </listitem>
- <listitem>
- <para><literal>up_thread</literal> is conceptually similar to down_thread, but here the queue and thread are for messages received from lower layers in the protocol stack.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>stats</literal> whether the protocol should gather runtime statistics on its operations that can be exposed via tools like the AS's administration console or the JGroups Probe utility. What, if any, statistics are gathered depends on the protocol. Default is <literal>true</literal>.
+ </para>
+ </listitem>
</itemizedlist>
-<para>Generally speaking, <literal>up_thread</literal> and <literal>down_thread</literal> should be set to false.
-</para>
+<note>
+ <para>All of the protocols in the versions of JGroups used in JBoss Application Server 3.x and 4.x exposed <literal>down_thread</literal> and <literal>up_thread</literal> attributes.
+ The JGroups version included in JBoss Application Server 5 and later no longer uses those attributes,
+ and a <literal>WARN</literal> message will be written to the server log if they are configured
+ for any protocol.</para>
+</note>
</section>
<section id="jgroups-transport">
<title>Transport Protocols</title>
- <para>The transport protocols send messages from one cluster node to another (unicast) or from cluster
- node to all other nodes in the cluster (mcast). JGroups supports UDP, TCP, and TUNNEL as transport
- protocols.</para>
+ <para>
+ The transport protocols send and receive messages to and from the network. They also
+ manage the thread pools used to deliver incoming messages to addresses higher in
+ the protocol stack. JGroups supports <literal>UDP</literal>, <literal>TCP</literal> and <literal>TUNNEL</literal> as transport protocols.
+ </para>
+
<note>
- <para>The <literal>UDP</literal>, <literal>TCP</literal>, and <literal>TUNNEL</literal> elements are
+ <para>The <literal>UDP</literal>, <literal>TCP</literal>, and <literal>TUNNEL</literal> protocols are
mutually exclusive. You can only have one transport protocol in each JGroups
<literal>Config</literal> element</para>
</note>
<section id="jgroups-transport-udp">
<title>UDP configuration</title>
- <para>UDP is the preferred protocol for JGroups. UDP uses multicast or multiple unicasts to send and
+ <para><para>UDP is the preferred protocol for JGroups. UDP uses multicast (or,
+ in an unusual configuration, multiple unicasts) to send and
receive messages. If you choose UDP as the transport protocol for your cluster service, you need
to configure it in the <literal>UDP</literal> sub-element in the JGroups
- <literal>Config</literal> element. Here is an example.</para>
-<programlisting><![CDATA[
-<UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}"
- mcast_port="${jboss.hapartition.mcast_port:45566}"
- tos="8"
- ucast_recv_buf_size="20000000"
- ucast_send_buf_size="640000"
- mcast_recv_buf_size="25000000"
- mcast_send_buf_size="640000"
- loopback="false"
- discard_incompatible_packets="true"
- enable_bundling="false"
- max_bundle_size="64000"
- max_bundle_timeout="30"
- use_incoming_packet_handler="true"
- use_outgoing_packet_handler="false"
- ip_ttl="${jgroups.udp.ip_ttl:2}"
- down_thread="false" up_thread="false"/>]]>
+ <literal>config</literal> element. Here is an example.</para>
+<programlisting><![CDATA[ <UDP
+ singleton_name="udp-async"
+ mcast_port="${jboss.jgroups.udp_async.mcast_port:45689}"
+ mcast_addr="${jboss.partition.udpGroup:228.11.11.11}"
+ tos="8"
+ ucast_recv_buf_size="20000000"
+ ucast_send_buf_size="640000"
+ mcast_recv_buf_size="25000000"
+ mcast_send_buf_size="640000"
+ loopback="true"
+ discard_incompatible_packets="true"
+ enable_bundling="true"
+ max_bundle_size="64000"
+ max_bundle_timeout="30"
+ ip_ttl="${jgroups.udp.ip_ttl:2}"
+ thread_naming_pattern="cl"
+ timer.num_threads="12"
+ enable_diagnostics="${jboss.jgroups.enable_diagnostics:true}"
+ diagnostics_addr="${jboss.jgroups.diagnostics_addr:224.0.0.75}"
+ diagnostics_port="${jboss.jgroups.diagnostics_port:7500}"
+
+ thread_pool.enabled="true"
+ thread_pool.min_threads="8"
+ thread_pool.max_threads="200"
+ thread_pool.keep_alive_time="5000"
+ thread_pool.queue_enabled="true"
+ thread_pool.queue_max_size="1000"
+ thread_pool.rejection_policy="discard"
+
+ oob_thread_pool.enabled="true"
+ oob_thread_pool.min_threads="8"
+ oob_thread_pool.max_threads="200"
+ oob_thread_pool.keep_alive_time="1000"
+ oob_thread_pool.queue_enabled="false"
+ oob_thread_pool.rejection_policy="discard"/>]]>
</programlisting>
- <para>The available attributes in the above JGroups configuration are listed below.</para>
+ <para>
+ This JGroups configuration has a number of attributes available. First we look
+ at the attributes available to the <literal>UDP</literal> protocol, followed
+ by the attributes that are also used by the <literal>TCP</literal> and
+ <literal>TUNNEL</literal> transport protocols.
+ </para>
+ <para>
+ The attributes particular to the <literal>UDP</literal> protocol are:
+ </para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">ip_mcast</emphasis> specifies whether or not to use IP
- multicasting. The default is <literal>true</literal>. If set to false, it will send n unicast packets rather than 1 multicast packet. Either way, packets are UDP datagrams.
- </para>
+ multicasting. The default is <literal>true</literal>. If set to <literal>false</literal>,
+ multiple unicast packets will be sent instead of one multicast packet. Any packet sent
+ via <literal>UDP</literal> protocol are UDP datagrams.
+ </para>
</listitem>
<listitem>
- <para><emphasis role="bold">mcast_addr</emphasis> specifies the multicast address (class D) for joining a group (i.e., the cluster). If omitted, the default is <literal>228.8.8.8
- </literal>.
- </para>
+ <para><emphasis role="bold">mcast_addr</emphasis> specifies the
+ multicast address (class D) for communicating with the group (i.e., the cluster).
+ The standard protocol stack configurations in JBoss AS use the
+ value of system property <literal>jboss.partition.udpGroup</literal>,
+ if set, as the value for this attribute. Using the <literal>-u</literal>
+ command line switch when starting JBoss Application Server sets that value.
+ See <xref linkend="clustering-jgroups-isolation"/> for information about using
+ this configuration attribute to ensure that JGroups channels are properly
+ isolated from one another.
+ If this attribute is omitted, the default value is <literal>228.8.8.8</literal>.
+ </para>
</listitem>
<listitem>
- <para><emphasis role="bold">mcast_port</emphasis> specifies the multicast port number. If omitted, the
- default is <literal>45566</literal>.</para>
- </listitem>
+ <para><emphasis role="bold">mcast_port</emphasis> specifies the port
+ to use for multicast communication with the group.
+ See <xref linkend="clustering-jgroups-isolation"/> for how to use this configuration attribute
+ to ensure JGroups channels are properly isolated from one another.
+ If this attribute is omitted, the default is <literal>45566</literal>.</para>
+ </listitem>
<listitem>
- <para><emphasis role="bold">bind_addr</emphasis> specifies the interface on which to receive and send multicasts (uses the <literal>-Djgroups.bind_address</literal> system property, if present). If you have a multihomed machine, set the <literal>bind_addr</literal> attribute or system property to the appropriate NIC IP address. By default, system property setting takes priority over XML attribute unless -Djgroups.ignore.bind_addr system property is set.</para>
+ <para>
+ <literal>mcast_send_buf_size</literal>, <literal>mcast_recv_buf_size</literal>,
+ <literal>ucast_send_buf_size</literal> and <literal>ucast_recv_buf_size</literal>
+ define the socket send and receive buffer sizes that JGroups will request
+ from the operating system. A large buffer size helps to ensure that packets are
+ not dropped due to buffer overflow. However, socket buffer sizes are limited at the
+ operating system level, so obtaining the desired buffer may require configuration
+ at the operating system level. See <xref linkend="jgroups-perf-udpbuffer"/> for further
+ details.</para>
+ </listitem>
+ <listitem>
+ <para><emphasis role="bold">bind_port</emphasis> specifies the port to
+ which the unicast receive socket should be bound. The default is
+ <literal>0</literal>; i.e. use an ephemeral port.</para>
</listitem>
<listitem>
- <para><emphasis role="bold">receive_on_all_interfaces </emphasis> specifies whether this node
- should listen on all interfaces for multicasts. The default is <literal>false</literal>.
- It overrides the <literal>bind_addr</literal> property for receiving multicasts.
- However, <literal>bind_addr</literal> (if set) is still used to send multicasts.</para>
+ <para><emphasis role="bold">port_range</emphasis> specifies the number of
+ ports to try if the port identified by <literal>bind_port</literal>
+ is not available. The default is <literal>1</literal>, which specifies that only
+ <literal>bind_port</literal> will be tried.</para>
</listitem>
- <listitem><para><emphasis role="bold">send_on_all_interfaces</emphasis> specifies whether this node send UDP packets via all the NICs if you have a multi NIC machine. This means that the same multicast message is sent N times, so use with care.
- </para>
- </listitem>
-
- <listitem>
- <para><emphasis role="bold">receive_interfaces</emphasis> specifies a list of of interfaces to receive multicasts on. The multicast receive socket will listen on all of these interfaces. This is a comma-separated list of IP addresses or interface names. E.g. "<literal>192.168.5.1,eth1,127.0.0.1</literal>".
- </para>
- </listitem>
-
-
<listitem>
- <para><emphasis role="bold">ip_ttl</emphasis> specifies time-to-live for IP Multicast packets. TTL is the commonly used term in multicast networking, but is actually something of a misnomer, since the value here refers to how many network hops a packet will be allowed to travel before networking equipment will drop it.
- </para>
+ <para><emphasis role="bold">ip_ttl</emphasis> specifies time-to-live (TTL) for IP Multicast packets. TTL is the commonly used term in multicast networking, but is actually something of a misnomer, since the value here refers to how many network hops a packet will be allowed to travel before networking equipment will drop it.
+ </para>
</listitem>
+ <para><emphasis role="bold">tos</emphasis> specifies the traffic class for sending unicast and multicast datagrams.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>The attributes that are common to all transport protocols,
+ and thus have the same meanings when used with <literal>TCP</literal> or
+ <literal>TUNNEL</literal>, are:
+ </para>
+ <itemizedlist>
+
<listitem>
- <para><emphasis role="bold">use_incoming_packet_handler</emphasis> specifies whether to use a separate thread to process incoming messages. Sometimes receivers are overloaded (they have to handle de-serialization etc). Packet handler is a separate thread taking care of de-serialization, receiver thread(s) simply put packet in queue and return immediately. Setting this to true adds one more thread. The default is <literal>true</literal>.</para>
+ <para><emphasis role="bold">singleton_name</emphasis> provides
+ a unique name for this transport protocol configuration. Used by the application server's <literal>ChannelFactory</literal>
+ to support sharing of a transport protocol instance by different channels
+ that use the same transport protocol configuration. See
+ <xref linkend="clustering-blocks-jgroups-sharedtransport"/>.</para>
</listitem>
<listitem>
- <para><emphasis role="bold">use_outgoing_packet_handler</emphasis> specifies whether to use a separate thread to process outgoing messages. The default is false.</para>
+ <para><emphasis role="bold">bind_addr</emphasis> specifies the interface
+ on which to receive and send messages.
+ By default, JGroups uses the value of system property <literal>jgroups.bind_addr</literal>.
+ This can also be set with the <literal>-b</literal> command line switch.
+ See <xref linkend="jgroups-other"/> for more on binding JGroups
+ sockets.</para>
</listitem>
<listitem>
- <para><emphasis role="bold">enable_bundling</emphasis> specifies whether to enable message bundling.
- If it is <literal>true</literal>, the node would queue outgoing messages until
- <literal>max_bundle_size</literal> bytes have accumulated, or
- <literal>max_bundle_time</literal> milliseconds have elapsed, whichever occurs
- first. Then bundle queued messages into a large message and send it. The messages are
- unbundled at the receiver. The default is <literal>false</literal>.</para>
+ <para>
+ <emphasis role="bold">receive_on_all_interfaces</emphasis> specifies whether this node
+ should listen on all interfaces for multicasts. The default is <literal>false</literal>.
+ It overrides the <literal>bind_addr</literal> property for receiving multicasts.
+ However, <literal>bind_addr</literal> (if set) is still used to send multicasts.</para>
</listitem>
+ <listitem><para><emphasis role="bold">send_on_all_interfaces</emphasis> specifies whether this node sends UDP packets via all available network interface controllers, if your machine has
+ multiple network interface controllers available. This means that the same multicast message is sent N times, so use with care.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis role="bold">receive_interfaces</emphasis> specifies a list of of interfaces on which to receive multicasts. The multicast receive socket will listen on all of these interfaces. This is a comma-separated list of IP addresses or interface names, for example, <literal>192.168.5.1,eth1,127.0.0.1</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis role="bold">send_interfaces</emphasis> specifies a
+ list of of interfaces via which to send multicasts. The multicast
+ sender socket will send on all of these interfaces. This is a
+ comma-separated list of IP addresses or interface names, for example,
+ <literal>192.168.5.1,eth1,127.0.0.1</literal>.This means that the
+ same multicast message is sent N times, so use with care.
+ </para>
+ </listitem>
<listitem>
- <para><emphasis role="bold">loopback</emphasis> specifies whether to loop outgoing message
- back up the stack. In <literal>unicast</literal> mode, the messages are sent to self. In
- <literal>mcast</literal> mode, a copy of the mcast message is sent. The default is <literal>false</literal></para>
+ <para><emphasis role="bold">enable_bundling</emphasis> specifies
+ whether to enable message bundling.
+ If <literal>true</literal>, the tranpsort protocol queues outgoing messages until
+ <literal>max_bundle_size</literal> bytes have accumulated, or
+ <literal>max_bundle_time</literal> milliseconds have elapsed, whichever occurs
+ first. Then the transport protocol bundles queued messages into one
+ large message and sends it. The messages are
+ unbundled at the receiver. The default is <literal>false</literal>.</para>
+ <para>Message bundling can have significant performance benefits for channels
+ that are used for high volume sending of messages where the sender does
+ not block waiting for a response from recipients (for example, a JBoss Cache
+ instance configured for <literal>REPL_ASYNC</literal>.) It can add considerable latency
+ to applications where senders need to block waiting for responses, so
+ it is not recommended for certain situations, such as where a JBoss Cache
+ instance is configured for <literal>REPL_SYNC</literal>.</para>
</listitem>
<listitem>
- <para><emphasis role="bold">discard_incompatibe_packets</emphasis> specifies whether to
- discard packets from different JGroups versions. Each message in the cluster is tagged
- with a JGroups version. When a message from a different version of JGroups is received,
- it will be discarded if set to true, otherwise a warning will be logged. The default is <literal>false</literal></para>
+ <para><emphasis role="bold">loopback</emphasis> specifies whether the thread sending a message
+ to the group should itself carry the message back up the stack for delivery. (Messages sent to
+ the group are always delivered to the sending node as well.) If
+ <literal>false</literal>, the sending thread does not carry the message;
+ the transport protocol waits to read the message off the network
+ and uses one of the message delivery pool threads for delivery.
+ The default is <literal>false</literal>, but <literal>true</literal> is recommended
+ to ensure that the channel receives its own messages, in case the network interface
+ goes down.</para>
</listitem>
+
+ <!--hajime-->
+
<listitem>
<para><emphasis role="bold">mcast_send_buf_size, mcast_recv_buf_size, ucast_send_buf_size,
ucast_recv_buf_size</emphasis> define receive and send buffer sizes. It is good to
More information about the jboss-cvs-commits
mailing list