[jboss-cvs] JBoss Messaging SVN: r3326 - in branches/Branch_Stable: tests/src/org/jboss/test/messaging/jms/clustering and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Nov 13 15:43:24 EST 2007
Author: timfox
Date: 2007-11-13 15:43:24 -0500 (Tue, 13 Nov 2007)
New Revision: 3326
Modified:
branches/Branch_Stable/docs/userguide/en/modules/c_configuration.xml
branches/Branch_Stable/docs/userguide/en/modules/configuration.xml
branches/Branch_Stable/tests/src/org/jboss/test/messaging/jms/clustering/SingletonCFTest.java
Log:
http://jira.jboss.org/jira/browse/JBMESSAGING-1149
Modified: branches/Branch_Stable/docs/userguide/en/modules/c_configuration.xml
===================================================================
--- branches/Branch_Stable/docs/userguide/en/modules/c_configuration.xml 2007-11-13 19:31:31 UTC (rev 3325)
+++ branches/Branch_Stable/docs/userguide/en/modules/c_configuration.xml 2007-11-13 20:43:24 UTC (rev 3326)
@@ -1,53 +1,111 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="c_configuration">
<title>JBoss Messaging Clustering Notes</title>
- <para>JBoss Messaging clustering should work out of the box in most cases
- with no configuration changes. It is however crucial that every node is
- assigned a unique server id, as specified in the installation guide.</para>
- <para>Every node deployed must have a unique id, including those in a
- particular LAN cluster, and also those only linked by mesage
- bridges.</para>
- <para>JBoss Messaging clusters JMS queues and topics transparently across
- the cluster. Messages sent to a distributed queue or topic on one node are
- consumable on other nodes. To designate that a particular destination is
- clustered simply set the clustered attribute in the destination deployment
- descriptor to true.</para>
- <para>JBoss Messaging balances messages between nodes, catering for faster
- or slower consumers to efficiently balance processing load across the
- cluster.</para>
- <para>JBoss Messaging durable subscrtiptions can also be clustered. This
- means multiple subscribers can consume from the same durable subscription
- from different nodes of the cluster. A durable subscription will be
- clustered if it's topic is clustered</para>
- <para>JBoss Messaging also supports clustered temporary topics and queues.
- All temporary topics and queues will be clustered if the post office is
- clustered</para>
- <para>If you don't want your nodes to participate in a cluster, or only
- have one non clustered server you can set the clustered attribute on the
- postoffice to false</para>
- <para>If you wish to apply strict JMS ordering to messages, such that a
- particular JMS consumer consumes messages in the same order as they were
- produced by a particular producer, you can set the DefaultPreserveOrdering
- attribute in the server peer to true. By default this is false. The
- side-effect of setting this to true is that messages cannot be distributed
- as freely around the cluster</para>
- <para>When pulling reliable messages from one node to another, JBoss
- Messaging can use client acnowledgement or an XA transaction. The default
- is client acknowledgement. Using XA transactions is a fairly heavyweight
- operation but ensures absolute once and only once delivery.</para>
- <para>If the call to send a persistent message to a persistent destination
- returns successfully with no exception, then you can be sure that the
- message was persisted. However if the call doesn't return successfully e.g.
- if an exception is thrown, then you *can't be sure the message wasn't
- persisted*. Since the failure might have occurred after persisting the
- message but before writing the response to the caller. This is a common
- attribute of any RPC type call: You can't tell by the call not returning
- that the call didn't actually succeed. Whether it's a web services call, an
- HTTP get request, an ejb invocation the same applies. The trick is to code
- your application so your operations are *idempotent* - i.e. they can be
- repeated without getting the system into an inconsistent state. With a
- message system you can do this on the application level, by checking for
- duplicate messages, and discarding them if they arrive. Duplicate checking
- is a very powerful technique that can remove the need for XA transactions
- in many cases.</para>
+
+ <section id="c_conf.serverpeerid">
+ <title>Unique server peer id</title>
+ <para>JBoss Messaging clustering should work out of the box in most cases
+ with no configuration changes. It is however crucial that every node is
+ assigned a unique server id, as specified in the installation guide.</para>
+ <para>Every node deployed must have a unique id, including those in a
+ particular LAN cluster, and also those only linked by mesage
+ bridges.</para>
+ </section>
+
+ <section id="c_conf.clustereddests">
+ <title>Clustered destinations</title>
+ <para>JBoss Messaging clusters JMS queues and topics transparently across
+ the cluster. Messages sent to a distributed queue or topic on one node are
+ consumable on other nodes. To designate that a particular destination is
+ clustered simply set the clustered attribute in the destination deployment
+ descriptor to true.</para>
+ <para>JBoss Messaging balances messages between nodes, catering for faster
+ or slower consumers to efficiently balance processing load across the
+ cluster.</para>
+ </section>
+
+ <section id="c_conf.clustereddursubs">
+ <title>Clustered durable subs</title>
+ <para>JBoss Messaging durable subscriptions can also be clustered. This
+ means multiple subscribers can consume from the same durable subscription
+ from different nodes of the cluster. A durable subscription will be
+ clustered if it's topic is clustered</para>
+ </section>
+
+ <section id="c_conf.clusteredtempdest">
+ <title>Clustered temporary destinations</title>
+ <para>JBoss Messaging also supports clustered temporary topics and queues.
+ All temporary topics and queues will be clustered if the post office is
+ clustered</para>
+ </section>
+
+ <section id="c_conf.nonclusteredserver">
+ <title>Non clustered servers</title>
+ <para>If you don't want your nodes to participate in a cluster, or only
+ have one non clustered server you can set the clustered attribute on the
+ postoffice to false</para>
+ </section>
+
+
+ <section id="c_conf.orderingincluster">
+ <title>Message ordering in the cluster</title>
+ <para>If you wish to apply strict JMS ordering to messages, such that a
+ particular JMS consumer consumes messages in the same order as they were
+ produced by a particular producer, you can set the DefaultPreserveOrdering
+ attribute in the server peer to true. By default this is false. The
+ side-effect of setting this to true is that messages cannot be distributed
+ as freely around the cluster</para>
+ </section>
+
+ <section id ="c_conf.messagepull">
+ <title>Transactional message pull</title>
+ <para>When pulling reliable messages from one node to another, JBoss
+ Messaging can use client acnowledgement or an XA transaction. The default
+ is client acknowledgement. Using XA transactions is a fairly heavyweight
+ operation but ensures absolute once and only once delivery.</para>
+ <para>It's a good idea to design your application to avoid message pull. A very common deployment scenario is
+ a bank of the same MDBS deployed on each node of the cluster with a well distributed set of producers sending messages
+ to different nodes of the cluster. In such a case message redistribution is probably unnecessary so you can turn
+ it off by setting the DisableRedistribution attribute of the destination to false.
+ </para>
+ </section>
+
+ <section id="c_conf.idempotentops">
+ <title>Idempotent operations</title>
+ <para>If the call to send a persistent message to a persistent destination
+ returns successfully with no exception, then you can be sure that the
+ message was persisted. However if the call doesn't return successfully e.g.
+ if an exception is thrown, then you *can't be sure the message wasn't
+ persisted*. Since the failure might have occurred after persisting the
+ message but before writing the response to the caller. This is a common
+ attribute of any RPC type call: You can't tell by the call not returning
+ that the call didn't actually succeed. Whether it's a web services call, an
+ HTTP get request, an ejb invocation the same applies. The trick is to code
+ your application so your operations are *idempotent* - i.e. they can be
+ repeated without getting the system into an inconsistent state. With a
+ message system you can do this on the application level, by checking for
+ duplicate messages, and discarding them if they arrive. Duplicate checking
+ is a very powerful technique that can remove the need for XA transactions
+ in many cases.</para>
+ </section>
+
+ <section id="c_conf.singletonconsumer">
+ <title>Singleton consumer</title>
+ <para>Sometimes you may want to guarantee that all messages from a specific queue are consumed sequentially by a single consumer. This can be accomplished by deploying a connection factory with attribute "Singleton" set to true on all nodes of the cluster.
+ JBoss Messaging will then ensure that the connection factory is only bound into JNDI on a single node at any one time.
+ You can then use HA JNDI from the client to look up the connection factory so you don't have to worry about what actual node it is deployed on. You then deploy the queue as a standard clustered queue on all nodes of the cluster with the attribute "DisableRedistribution" set to true to prevent messages being redistributed between queue instances.
+ </para>
+ </section>
+
+ <section id="c_conf.clusteredcfs">
+ <title>Clustered connection factories</title>
+ <para>If the supportsLoadBalancing attribute of the connection factory is set to true then consecutive create connection attempts will round robin between available servers. The first node to try is chosen randomly</para>
+ <para>If the supportsFailover attribute of the connection factory is set to true then automatic failover is enabled.
+ This will automatically failover from one server to another, transparently to the user, in case of failure.</para>
+ <para>If automatic failover is not required or you wish to do manual failover (JBoss MQ style) this can be set to false, and you can supply a standard JMS ExceptionListener on the connection which will be called in case of
+ connection failure. You would then need to manually close the connection, lookup a new connection factory from
+ HA JNDI and recreate the connection.</para>
+
+ </section>
+
</chapter>
\ No newline at end of file
Modified: branches/Branch_Stable/docs/userguide/en/modules/configuration.xml
===================================================================
--- branches/Branch_Stable/docs/userguide/en/modules/configuration.xml 2007-11-13 19:31:31 UTC (rev 3325)
+++ branches/Branch_Stable/docs/userguide/en/modules/configuration.xml 2007-11-13 20:43:24 UTC (rev 3326)
@@ -1347,6 +1347,14 @@
<para>The number of consumers currently consuming from the
queue.</para>
</section>
+ <section id="conf.destination.queue.attributes.disableredistribution">
+ <title>DisableRedistribution</title>
+ <para>By default JBM will distribute messages between nodes for queue or topic according to load.
+ If you want each partial queue to act as indepenedent queue, set this to true.
+ This parameter is used as part of the Singleton Consumer pattern when you want to ensure
+ all messages in a queue are processed sequentially by a single consumer.
+ See the clustering configuration section for more information.</para>
+ </section>
</section>
<section id="conf.destination.queue.operations">
<title>We now discuss the MBean operations of the Queue
@@ -1563,6 +1571,14 @@
<para>The count of all non durable subscriptions on this
topic</para>
</section>
+ <section id="conf.destination.queue.attributes.disableredistribution">
+ <title>DisableRedistribution</title>
+ <para>By default JBM will distribute messages between nodes for queue or topic according to load.
+ If you want each partial queue to act as indepenedent queue, set this to true.
+ This parameter is used as part of the Singleton Consumer pattern when you want to ensure
+ all messages in a queue are processed sequentially by a single consumer.
+ See the clustering configuration section for more information.</para>
+ </section>
</section>
<section id="conf.destination.topic.operations">
<title>We now discuss the MBean operations of the Topic
@@ -1693,6 +1709,8 @@
<attribute name="SlowConsumers">false</attribute>
+ <attribute name="Singleton">false</attribute>
+
<attribute name="StrictTck">true</attribute>
<attribute name="DefaultTempQueueFullSize">50000</attribute>
@@ -1749,6 +1767,12 @@
make sure they don't buffer any messages. Since this can prevent
them from being consumed by faster consumers.</para>
</section>
+ <section id="conf.connectionfactory.attributes.singleton">
+ <title>Singleton</title>
+ <para>If this is true. Then JBoss Messaging will ensure that the connection factory is only bound
+ in JNDI on a single server at any one time. This is useful when you want to implement the Singleton
+ Consumer pattern. See the clustering configuration section for more details</para>
+ </section>
<section id="conf.connectionfactory.attributes.tckstrictbehavior">
<title>StrictTck</title>
<para>Set this to true if you want strict JMS behaviour as
Modified: branches/Branch_Stable/tests/src/org/jboss/test/messaging/jms/clustering/SingletonCFTest.java
===================================================================
--- branches/Branch_Stable/tests/src/org/jboss/test/messaging/jms/clustering/SingletonCFTest.java 2007-11-13 19:31:31 UTC (rev 3325)
+++ branches/Branch_Stable/tests/src/org/jboss/test/messaging/jms/clustering/SingletonCFTest.java 2007-11-13 20:43:24 UTC (rev 3326)
@@ -259,7 +259,6 @@
}
}
-
// Private --------------------------------------------------------------------------------------
private void deployCF(String name, int node) throws Exception
More information about the jboss-cvs-commits
mailing list