[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><broadcast-groups>
+ <broadcast-group name="my-broadcast-group">
+ <local-bind-port>54321</local-bind-port>
+ <group-address>231.7.7.7</group-address>
+ <group-port>9876</group-port>
+ <broadcast-period>1000</broadcast-period>
+ <connector-ref connector-name="netty-connector" backup-connector-name="backup-connector"/>
+ </broadcast-group>
+</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><discovery-groups>
+ <discovery-group name="my-discovery-group">
+ <group-address>231.7.7.7</group-address>
+ <group-port>9876</group-port>
+ <refresh-timeout>10000</refresh-timeout>
+ </discovery-group>
+</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><connection-factory name="ConnectionFactory">
+ <discovery-group-ref discovery-group-name="my-discovery-group"/>
+ <entries>
+ <entry name="ConnectionFactory"/>
+ </entries>
+</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>
+<cluster-connections>
+ <cluster-connection name="my-cluster">
+ <address>jms</address>
+ <retry-interval>500</retry-interval>
+ <use-duplicate-detection>true</use-duplicate-detection>
+ <forward-when-no-consumers>false</forward-when-no-consumers>
+ <max-hops>1</max-hops>
+ <discovery-group-ref discovery-group-name="my-discovery-group"/>
+ </cluster-connection>
+</cluster-connections>
+ </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>
+<connection-factory name="ConnectionFactory">
+ <discovery-group-ref discovery-group-name="my-discovery-group"/>
+ <entries>
+ <entry name="ConnectionFactory"/>
+ </entries>
+ <connection-load-balancing-policy-class-name>org.jboss.messaging.core.client.impl.RandomConnectionLoadBalancingPolicy</connection-load-balancing-policy-class-name>
+</connection-factory>
+ </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 @@
<connector-ref connector-name="remote-connector" backup-connector-name="backup-remote-connector"/>
</bridge>
</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