[jboss-cvs] JBoss Messaging SVN: r6807 - trunk/docs/user-manual/en/modules.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Fri May 15 09:52:13 EDT 2009


Author: timfox
Date: 2009-05-15 09:52:12 -0400 (Fri, 15 May 2009)
New Revision: 6807

Modified:
   trunk/docs/user-manual/en/modules/clusters.xml
   trunk/docs/user-manual/en/modules/core-bridges.xml
   trunk/docs/user-manual/en/modules/filter-expressions.xml
Log:
more on clustering docs

Modified: trunk/docs/user-manual/en/modules/clusters.xml
===================================================================
--- trunk/docs/user-manual/en/modules/clusters.xml	2009-05-15 13:31:35 UTC (rev 6806)
+++ trunk/docs/user-manual/en/modules/clusters.xml	2009-05-15 13:52:12 UTC (rev 6807)
@@ -1,35 +1,491 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter id="clusters">
     <title>Clusters</title>
-    <para>blah</para>
+    <para>In this chapter we discuss the concepts behind JBoss Messaging clusters, and how to
+        configure them.</para>
     <section>
         <title>Clusters Overview</title>
-        <para></para>
+        <para>JBoss Messaging clusters allow groups of JBoss Messaging servers to be grouped
+            together in order to share message processing load. Each active node in the cluster an
+            active JBoss Messaging server which manages its own messages and handles its own
+            connections.</para>
+        <para>The cluster is formed by each node declaring cluster connections to other nodes in the
+            core configuration file <literal>jbm-configuration.xml</literal>. When a node forms a
+            cluster connection to another node, internally it creates a core bridge (LINK)
+            connection between it and the other node, this is done transparently behind the scenes -
+            you don't have to declare an explicit bridge for each node. These cluster connections
+            allow messages to flow between the nodes of the cluster to balance load.</para>
+        <para>Nodes can be connected together to form a cluster in many different topologies, we
+            will discuss the more common topologies in this chapter</para>
+        <itemizedlist>
+            <listitem>
+                <para>Symmetric cluster. In this topology every node is connected symmetrically to
+                    every other node in the cluster.</para>
+            </listitem>
+            <listitem>
+                <para>Chain cluster.</para>
+            </listitem>
+            <listitem>
+                <para>Chain cluster with mediator.</para>
+            </listitem>
+        </itemizedlist>
+        <para>We'll also discuss client side load balancing, where we can balance client connections
+            across the nodes of the cluster, and we'll talk about message redistribution where JBoss
+            Messaging will redistribute messages between nodes to avoid starvation.</para>
     </section>
     <section>
-        <title>Client-Side Load balancing</title>
-        <para></para>
+        <title>Server discovery</title>
+        <para>Server discovery is a mechanism by which servers can broadcast their connection
+            settings across the network. This is useful for two purposes:</para>
+        <itemizedlist>
+            <listitem>
+                <para>Discovery by messaging clients. A messaging client wants to be able to connect
+                    to the servers of the cluster without having specific knowledge of which servers
+                    in the cluster are up at any one time. Messaging clients can initialised with an
+                    explicit list of the servers in a cluster, but this is not flexible or maintable
+                    as servers are added or removed from the cluster.</para>
+            </listitem>
+            <listitem>
+                <para>Discovery by other servers. Servers in a cluster want to be able to create
+                    cluster connections to each other without having prior knowledge of all the
+                    other servers in the cluster. </para>
+            </listitem>
+        </itemizedlist>
+        <para>Server discovery uses UDP (LINK) multicast to broadcast server connection settings. If
+            UDP is disabled on your network you won't be able to use this, and will have to specify
+            servers explicitly when setting up a cluster or using a messaging client.</para>
+        <section>
+            <title>Broadcast Groups</title>
+            <para>A broadcast group is the means by which a server broadcasts connectors over the
+                network. A connector defines a way in which a client (or other server) can make
+                connections to the server. For more information on what a connector is please see
+                chapter [LINK].</para>
+            <para>The broadcast group takes a set of connector pairs, each connector pair containing
+                connection settings for a live and (optional) backup server and broadcasts them on
+                the network. It also defines the UDP address and port settings. </para>
+            <para>Broadcast groups are defined in the server configuration file <literal
+                    >jbm-configuration.xml</literal>. There can be many broadcast groups per JBoss
+                Messaging server. All broadcast groups must be defined in a <literal
+                    >broadcast-groups</literal> element.</para>
+            <para>Let's take a look at an example broadcast group from <literal
+                    >jbm-configuration.xml</literal>:</para>
+            <programlisting>&lt;broadcast-groups>
+   &lt;broadcast-group name="my-broadcast-group">
+      &lt;local-bind-port>54321&lt;/local-bind-port>
+      &lt;group-address>231.7.7.7&lt;/group-address>
+      &lt;group-port>9876&lt;/group-port>
+      &lt;broadcast-period>1000&lt;/broadcast-period>
+      &lt;connector-ref connector-name="netty-connector" backup-connector-name="backup-connector"/>
+   &lt;/broadcast-group>
+&lt;/broadcast-groups></programlisting>
+            <para>Some of the broadcast group parameters are optional and you'll normally use the
+                defaults, but we specify them all in the above example for clarity. Let's discuss
+                each one in turn:</para>
+            <itemizedlist>
+                <listitem>
+                    <para><literal>name</literal> attribute. Each broadcast group in the server must
+                        have a unique name. </para>
+                </listitem>
+                <listitem>
+                    <para><literal>local-bind-address</literal>. TODO. This is the local bind
+                        address that the datagram socket is bound to. If you have multiple network
+                        interfaces on your server, you would specify which one you wish to use for
+                        broadcasts by setting this property. If this property is not specified then
+                        TODO TODO</para>
+                </listitem>
+                <listitem>
+                    <para><literal>local-bind-port</literal>. If you want to specify a local port to
+                        which the datagram socket is bound you can specify it here. Normally you
+                        would just use the default value of <literal>-1</literal> which signifies
+                        that an anonymous port should be used.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>group-address</literal>. This is the multicast address to which
+                        the data will be broadcast. It is a class D IP address in the range
+                        224.0.0.0 to 239.255.255.255, inclusive. The address 224.0.0.0 is reserved
+                        and is not available for use. This parameter is mandatory.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>group-port</literal>. This is the UDP port number used for
+                        broadcasting. This parameter is mandatory.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>broadcast-period</literal>. This is the period in milliseconds
+                        between consecutive broadcasts. This parameter is optional, the default
+                        value is <literal>1000</literal> milliseconds.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>connector-ref</literal>. This specifies the connector and
+                        optional backup connector that will be broadcast. Please see section [LINK]
+                        for more information on connectors. The connector to be broadcast is
+                        specified by the <literal>connector-name</literal> attribute, and the backup
+                        connector to be broadcast is specified by the <literal
+                            >backup-connector</literal> attribute. The <literal
+                            >backup-connector</literal> attribute is optional.</para>
+                </listitem>
+            </itemizedlist>
+        </section>
+        <section>
+            <title>Discovery Groups</title>
+            <para>While the broadcast group defines who connector information is broadcast from a
+                server, a discovery group defines how connector information is received from a
+                multicast address.</para>
+            <para>A discovery group maintains a list of connector pairs - one for each broadcast by
+                a different server. As it receives broadcasts on the multicast group address from a
+                particular server it updates its entry in the list for that server.</para>
+            <para>If it has not received a broadcast from a particular server for a length of time
+                it will remove that server's entry from its list.</para>
+            <para>Discovery groups are used in two places in JBoss Messaging:</para>
+            <itemizedlist>
+                <listitem>
+                    <para>By cluster connections so they know what other servers in the cluster they
+                        should make connections to.</para>
+                </listitem>
+                <listitem>
+                    <para>By messaging clients so they can discovery what servers in the cluster
+                        that they can connect to.</para>
+                </listitem>
+            </itemizedlist>
+        </section>
+        <section>
+            <title>Defining Discovery Groups on the Server</title>
+            <para>For cluster connections, discovery groups are defined in the server side
+                configuration file <literal>jbm-configuration.xml</literal>. All discovery groups
+                must be defined inside a <literal>discovery-groups</literal> element. There can be
+                many discovery groups defined by JBoss Messaging server. Let's look at an
+                example:</para>
+            <programlisting>&lt;discovery-groups>
+   &lt;discovery-group name="my-discovery-group">
+      &lt;group-address>231.7.7.7&lt;/group-address>
+      &lt;group-port>9876&lt;/group-port>
+      &lt;refresh-timeout>10000&lt;/refresh-timeout>
+   &lt;/discovery-group>
+&lt;/discovery-groups></programlisting>
+            <para>We'll consider each parameter of the discovery group:</para>
+            <itemizedlist>
+                <listitem>
+                    <para><literal>name</literal> attribute. Each discovery group must have a unique
+                        name per server.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>group-address</literal>. This is the multicast ip address of the
+                        group to listen on. It should match the <literal>group-address</literal> in
+                        the broadcast group that you wish to listen from. This parameter is
+                        mandatory.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>group-port</literal>. This is the UDP port of the multicast
+                        group. It should match the <literal>group-port</literal> in the broadcast
+                        group that you wish to listen from. This parameter is mandatory.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>refresh-timeout</literal>. This is the period the discovery group
+                        waits after receiving the last broadcast from a particular server before
+                        removing that servers connector pair entry from its list. You would normally
+                        set this to a value significantly higher than the <literal
+                            >broadcast-period</literal> on the broadcast group otherwise servers
+                        might intermittently disappear from the list even though they are still
+                        broadcasting due to slight differences in timing. This parameter is
+                        optional, the default value is <literal>10000</literal> milliseconds (10
+                        seconds).</para>
+                </listitem>
+            </itemizedlist>
+        </section>
+        <section>
+            <title>Discovery Groups on the Client Side</title>
+            <para>Let's discuss how to configure a JBoss Messaging client to use discovery to
+                discover a list of servers to which it can connect. The way to do this differs
+                depending on whether you're using JMS or the core API.</para>
+            <section>
+                <title>Configuring client discovery using JMS</title>
+                <para>If you're using JMS and you're also using the JMS Service on the server to
+                    load your JMS connection factory instances into JNDI, then you can specify which
+                    discovery group to use for your JMS connection factory in the server side xml
+                    configuration <literal>jbm-jms.xml</literal>. Let's take a look at an
+                    example:</para>
+                <programlisting>&lt;connection-factory name="ConnectionFactory">
+   &lt;discovery-group-ref discovery-group-name="my-discovery-group"/>
+    &lt;entries>
+       &lt;entry name="ConnectionFactory"/>
+    &lt;/entries>
+&lt;/connection-factory></programlisting>
+                <para>The element <literal>discovery-group-ref</literal> specifies the name of a
+                    discovery group defined in <literal>jbm-configuration.xml</literal>.</para>
+                <para>When this connection factory is downloaded from JNDI by a client application
+                    and JMS connections are created from it, those connections will be load-balanced
+                    across the list of servers that the discovery group maintains by listening on
+                    the multicast address specified in the discovery group configuration. For more
+                    information on client side connection load balancing please see [LINK].</para>
+                <para>If you're using JMS, but you're not using JNDI to lookup a connection factory
+                    - you're instantiating the JMS connection factory directly then you can specify
+                    the discovery group parameters directly when creating the JMS connection
+                    factory. Here's an
+                    example:<programlisting>final String groupAddress = "231.7.7.7";
+
+final int groupPort = 9876;
+
+ConnectionFactory jmsConnectionFactory = new JBossConnectionFactory(groupAddress, groupPort);
+
+Connection jmsConnection1 = jmsConnectionFactory.createConnection();
+
+Connection jmsConnection2 = jmsConnectionFactory.createConnection();</programlisting></para>
+                <para>The <literal>refresh-timeout</literal> can be set directly on the connection
+                    factory by using the setter method <literal>setDiscoveryRefreshTimeout() if you
+                        want to change the default value.</literal></para>
+                <para>There is also a further parameter settable on the connection factory using the
+                    setter method <literal>setInitialWaitTimeout()</literal>. If the connection
+                    factory is used immediately after creation then it may not have had enough time
+                    to received broadcasts from all the nodes in the cluster. On first usage, the
+                    connection factory will make sure it waits this long since creation before
+                    creating the first connection. The default value for this parameter is <literal
+                        >2000</literal> milliseconds.</para>
+            </section>
+            <section>
+                <title>Configuring client discovery using Core</title>
+                <para>If you're using the core API to directly instantiate <literal
+                        >ClientSessionFactory</literal> instances, then you can specify the
+                    discovery group parameters directly when creating the session factory. Here's an
+                    example:final String groupAddress = "231.7.7.7";                          final
+                    int groupPort = 9876;                          SessionFactory factory = new
+                    ClientSessionFactoryImpl(groupAddress, groupPort);
+                    ClientSession session1 = factory.createClientSession(...);  ClientSession
+                    session2 = factory.createClientSession(...);                         </para>
+                <para>The <literal>refresh-timeout</literal> can be set directly on the session
+                    factory by using the setter method <literal>setDiscoveryRefreshTimeout() if you
+                        want to change the default value.</literal></para>
+                <para>There is also a further parameter settable on the session factory using the
+                    setter method <literal>setInitialWaitTimeout()</literal>. If the session factory
+                    is used immediately after creation then it may not have had enough time to
+                    received broadcasts from all the nodes in the cluster. On first usage, the
+                    session factory will make sure it waits this long since creation before creating
+                    the first session. The default value for this parameter is <literal
+                        >2000</literal> milliseconds.</para>
+            </section>
+        </section>
     </section>
     <section>
-        <title>Message load balancing</title>
-        <para></para>
+        <title>Server-Side Message Load Balancing</title>
+        <para>If cluster connections are defined between nodes of a cluster, then JBoss Messaging
+            will load balance messages arriving from at a particular node from a client.</para>
+        <para>Let's take a simple example of a cluster of four nodes A, B, C, and D arranged in a
+            symmetric cluster [LINK]. We have a queue called <literal>OrderQueue</literal> deployed
+            on each node of the cluster.</para>
+        <para>We have client Ca connected to node A, sending orders to the server. We have also have
+            order processor clients Pa, Pb, Pc, and Pd connected to each of the nodes A, B, C, D. If
+            no cluster connection was defined on node A, then as order messages arrive on node A
+            they will all end up in the <literal>OrderQueue</literal> on node A, so will only get
+            consumed by the order processor client attached to node A, Pa.</para>
+        <para>If we define a cluster connection on node A, then as order messages arrive on node A
+            instead of all of them going into the local <literal>OrderQueue</literal> instance, they
+            are distributed in a round-robin fashion between all the nodes of the cluster. The
+            messages are forwarded from the receiving node to other nodes of the cluster. This is
+            all done on the server side, the client maintains a single connection to node A.</para>
+        <para>For example, messages arriving on node A might be distributed in the following order
+            between the nodes: B, D, C, A, B, D, C, A, B, D. The exact order depends on the order
+            the nodes started up, but the algorithm used is round robin.</para>
+        <para>JBoss Messaging cluster connections can be configured to always blindly load balance
+            messages in a round robin fashion irrespective of whether there are any matching
+            consumers on other nodes, but they can be a bit cleverer than that and also be
+            configured to only distribute to other nodes if they have matching consumers. We'll look
+            at both these cases in turn with some examples, but first we'll discuss configuring
+            cluster connections in general.</para>
+        <section>
+            <title>Configuring Cluster Connections</title>
+            <para>Cluster Connections group servers into clusters so that messages can be load
+                balanced between the nodes of the cluster. Let's take a look at a typical cluster
+                connection. Cluster connections are always defined in <literal
+                    >jbm-configuration.xml</literal> inside a <literal>cluster-connection</literal>
+                element. There can be zero or more cluster connections defined per JBoss Messaging
+                server.</para>
+            <programlisting>
+&lt;cluster-connections&gt;
+    &lt;cluster-connection name="my-cluster"&gt;
+        &lt;address&gt;jms&lt;/address&gt;
+        &lt;retry-interval&gt;500&lt;/retry-interval&gt;
+        &lt;use-duplicate-detection&gt;true&lt;/use-duplicate-detection&gt;
+        &lt;forward-when-no-consumers&gt;false&lt;/forward-when-no-consumers&gt;
+        &lt;max-hops&gt;1&lt;/max-hops&gt;
+        &lt;discovery-group-ref discovery-group-name="my-discovery-group"/&gt;
+    &lt;/cluster-connection&gt;
+&lt;/cluster-connections&gt;                
+            </programlisting>
+            <para>In the above cluster connection all parameters have been explicity specified. In
+                practice you might use the defaults for some.</para>
+            <itemizedlist>
+                <listitem>
+                    <para><literal>address</literal>. Each cluster connection only applies to
+                        messages sent to an address that starts with this value.</para>
+                    <para>In this case, this cluster connection will load balance messages sent to
+                        address that start with <literal>jms</literal>. This cluster connection,
+                        will, in effect apply to all JMS Queue and topic subscriptions since they
+                        map to core queues that start with the substring "jms"</para>
+                    <para>The address can be any value and you can have many cluster connections
+                        with different values of <literal>address</literal>, simultaneously
+                        balancing messages for those addresses, potentially to different clusters of
+                        servers. By having multiple cluster connections on different addresses a
+                        single JBoss Messaging Server can effectively take part in multiple clusters
+                        simultaneously.</para>
+                    <para>By careful not to have multiple cluster connections with overlapping
+                        values of <literal>address</literal>, e.g. "europe" and "europe.news" since
+                        this could result in the same messages being distributed between more than
+                        one cluster connection, possibly resulting in duplicate deliveries. </para>
+                    <para>This parameter is mandatory.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>retry-interval</literal>. We mentioned before that, internally,
+                        cluster connections cause bridges to be created between the nodes of the
+                        cluster. If the cluster connection is created and the target node has not
+                        been started, or say, is being rebooted, then the cluster connections from
+                        other nodes will retry connecting to the target until it comes back up, in
+                        the same way as a bridge does.</para>
+                    <para>This parameter determines the interval in milliseconds between retry
+                        attempts. It has the same meaning as the <literal>retry-interval</literal>
+                        on a bridge [LINK].</para>
+                    <para>This parameter is optional and its default value is <literal>500</literal>
+                        milliseconds.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>use-duplicate-detection</literal>. Internally cluster connections
+                        use bridges to link the nodes, and bridges can be configured to add a
+                        duplicate id property in each message that is forwarded. If the target node
+                        of the bridge crashes and then recovers, messages might be resent from the
+                        source node. By enabling duplicate detection any duplicate messages will be
+                        filtered out and ignored on receipt at the target node.</para>
+                    <para>This parameter has the same meaning as <literal
+                            >use-duplicate-detection</literal> on a bridge. For more information on
+                        duplicate detection please see chapter [LINK].</para>
+                    <para>This parameter is optional and has a default value of <literal
+                            >true</literal>.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>forward-when-no-consumers</literal>. This parameter determines
+                        whether messages will be distributed round robin between other nodes of the
+                        cluster <emphasis>irrespective</emphasis> of whether there are matching or
+                        indeed any consumers on other nodes. </para>
+                    <para>If this is set to <literal>true</literal> then each incoming message will
+                        be round robin'd even though the same queues on the other nodes of the
+                        cluster may have no consumers at all, or they may have consumers that have
+                        non matching message filters (selectors).Note that JBoss Messaging will
+                            <emphasis>not</emphasis> forward messages to other nodes if there are no
+                            <emphasis>queues</emphasis> of the same name on the other nodes, even if
+                        this parameter is set to <literal>true</literal>.</para>
+                    <para>If this is set to <literal>false</literal> then JBoss Messaging will only
+                        forward messages to other nodes of the cluster if the address to which they
+                        are being forwarded has queues which have consumers, and if those consumers
+                        have message filters (selectors) at least one of those selectors must match
+                        the message.</para>
+                    <para>We will discuss this more fully later in the chapter.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>max-hops</literal>. When a cluster connection decides the set of
+                        nodes to which it might load balance a message, those nodes do not have to
+                        be directly connected to it via a cluster connection. JBoss Messaging can be
+                        configured to also load balance messages to nodes which might be connected
+                        to it only indirectly with other JBoss Messaging servers as intermediates in
+                        a chain.</para>
+                    <para>This allows JBoss Messaging to be configured in more complex topologies
+                        and still provide message load balancing. We'll discuss this more later in
+                        this chapter.</para>
+                    <para>The default value for this parameter is <literal>1</literal>, which means
+                        messages are only load balanced to other JBoss Messaging serves which are
+                        directly connected to this server. This parameter is optional.</para>
+                </listitem>
+                <listitem>
+                    <para><literal>discovery-group-ref</literal>. This parameter determines which
+                        discovery group is used to obtain the list of other servers in the cluster
+                        that this cluster connection will make connections to. For more information
+                        on discovery groups please see section [LINK].</para>
+                </listitem>
+            </itemizedlist>
+        </section>
+        <section>
+            <title>Forwarding Irrespective of Consumers</title>
+            <para>Here's an example of a cluster connection that's configured to always forward
+                messages even when there are no matching consumers on the addresses on the other
+                nodes.</para>
+            <programlisting>
+                
+            </programlisting>
+        </section>
     </section>
     <section>
+        <title>Client-Side Load balancing</title>
+        <para>With JBoss Messaging client-side connection load balancing subsequent client
+            connections created using a single factory can be made to different nodes of the
+            cluster. This allows connections to spread smoothly across the nodes of a cluster and
+            not "clumped" on any particular node.</para>
+        <para>The load balancing policy to be used by the client factory is configurable. JBoss
+            Messaging provides two out-of-the-box load balancing policies and you can also implement
+            your own and use that.</para>
+        <para>The out-of-the-box policies are</para>
+        <itemizedlist>
+            <listitem>
+                <para>Round Robin. With this policy the first node is chosen randomly then each
+                    subsequent node is chosen sequentially in the same order.</para>
+                <para>For example nodes might be chosen in the order B, C, D, A, B, C, D, A, B or D,
+                    A, B, C, A, B, C, D, A or C, D, A, B, C, D, A, B, C, D, A.</para>
+            </listitem>
+            <listitem>
+                <para>Random. With this policy each node is chosen randomly.</para>
+            </listitem>
+        </itemizedlist>
+        <para>You can also implement your own policy by implementing the interface <literal
+                >org.jboss.messaging.core.client.ConnectionLoadBalancingPolicy</literal></para>
+        <para>Specifying which load balancing policy to use differs whether you are using JMS or the
+            core API. If you don't specify a policy then the default will be used which is <literal
+                >org.jboss.messaging.core.client.impl.RoundRobinConnectionLoadBalancingPolicy</literal>.</para>
+        <para>If you're using JMS, and you're using JNDI on the server to put your JMS connection
+            factories into JNDI, then you can specify the load balancing policy directly in the
+                <literal>jbm-jms.xml</literal> configuration file on the server as follows:
+            <programlisting>
+&lt;connection-factory name="ConnectionFactory"&gt;
+    &lt;discovery-group-ref discovery-group-name="my-discovery-group"/&gt;
+    &lt;entries&gt;
+        &lt;entry name="ConnectionFactory"/&gt;
+    &lt;/entries&gt;
+            &lt;connection-load-balancing-policy-class-name&gt;org.jboss.messaging.core.client.impl.RandomConnectionLoadBalancingPolicy&lt;/connection-load-balancing-policy-class-name&gt;
+&lt;/connection-factory&gt;            
+        </programlisting>
+            The above example would deploy a JMS connection factory that uses the random connection
+            load balancing policy. </para>
+        <para>If you're using JMS but you're instantiating your connection factory directly on the
+            client side then you can set the load balancing policy using the setter on the <literal
+                >JBossConnectionFactory</literal> before using it:
+            <programlisting>
+ConnectionFactory jmsConnectionFactory = new JBossConnectionFactory(...);
+jmsConnectionFactory.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
+        </programlisting></para>
+        <para>If you're using the core API, you can set the load balancing policy directly on the
+                <literal>ClientSessionFactory</literal> instance you are using:
+            <programlisting>
+ClientSessionFactory factory = new ClientSessionFactoryImpl(...);
+factory.setLoadBalancingPolicyClassName("com.acme.MyLoadBalancingPolicy");
+            </programlisting></para>
+        <para>The set of servers over which the factory load balances can be determined in one of
+            two ways:</para>
+        <itemizedlist>
+            <listitem>
+                <para>Specifying servers explicitly</para>
+            </listitem>
+            <listitem>
+                <para>Using discovery</para>
+            </listitem>
+        </itemizedlist>
+    </section>
+    <section>
         <title>Message Redistribution</title>
-        <para></para>
+        <para/>
     </section>
     <section>
         <title>Cluster topologies</title>
-        <para></para>
+        <para/>
         <section>
             <title>Symmetric cluster</title>
-            <para></para>
+            <para/>
         </section>
         <section>
             <title>Chain cluster</title>
-            <para></para>
+            <para/>
         </section>
     </section>
-
-   
 </chapter>

Modified: trunk/docs/user-manual/en/modules/core-bridges.xml
===================================================================
--- trunk/docs/user-manual/en/modules/core-bridges.xml	2009-05-15 13:31:35 UTC (rev 6806)
+++ trunk/docs/user-manual/en/modules/core-bridges.xml	2009-05-15 13:52:12 UTC (rev 6807)
@@ -45,6 +45,8 @@
     &lt;connector-ref connector-name="remote-connector" backup-connector-name="backup-remote-connector"/&gt;          
 &lt;/bridge&gt;                        
         </programlisting>
+        <para>Please also note that in order for bridges to be deployed on a server, the <literal>clustered</literal> attribute needs to be set
+        to <literal>true</literal> in <literal>jbm-configuration.xml</literal>.</para>
         <para>In the above example we should all the parameters its possible to configure for a
             bridge. In practice you might use many of the defaults so it won't be necessary to
             specify them all explicitly.</para>

Modified: trunk/docs/user-manual/en/modules/filter-expressions.xml
===================================================================
--- trunk/docs/user-manual/en/modules/filter-expressions.xml	2009-05-15 13:31:35 UTC (rev 6806)
+++ trunk/docs/user-manual/en/modules/filter-expressions.xml	2009-05-15 13:52:12 UTC (rev 6807)
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <chapter id="filter-expressions">
     <title>Filter Expressions</title>
-    <para>blah</para>
+    <para></para>
     
     
 </chapter>




More information about the jboss-cvs-commits mailing list