[jboss-cvs] JBoss Messaging SVN: r7957 - projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Feb 23 00:34:41 EST 2010
Author: benlc
Date: 2010-02-23 00:34:41 -0500 (Tue, 23 Feb 2010)
New Revision: 7957
Modified:
projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US/configuration.xml
projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US/ordering_group.xml
Log:
'committing changes relating to JBPAPP-3720 and JBPAPP-3757'
Modified: projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US/configuration.xml
===================================================================
--- projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US/configuration.xml 2010-02-22 12:57:32 UTC (rev 7956)
+++ projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US/configuration.xml 2010-02-23 05:34:41 UTC (rev 7957)
@@ -149,7 +149,7 @@
<para>The unique id of the server peer. Every node you deploy MUST
have a unique id. This applies whether the different nodes form a
cluster, or are only linked via a message bridge. The id must be a
- valid integer.</para>
+ valid integer between 0 and 1023.</para>
</formalpara>
<formalpara>
Modified: projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US/ordering_group.xml
===================================================================
--- projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US/ordering_group.xml 2010-02-22 12:57:32 UTC (rev 7956)
+++ projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_7/en-US/ordering_group.xml 2010-02-23 05:34:41 UTC (rev 7957)
@@ -4,37 +4,71 @@
<chapter>
<title>Enabling JBoss Messaging Ordering Group</title>
- <para>This section describes how to use JBoss Messaging ordering group feature to achieve strict message ordering.
+ <para>
+ This section describes how to use the JBoss Messaging ordering group feature to achieve strict message ordering.
</para>
- <para>JBoss Messaging's implementation of strict message ordering is called message ordering groups. Messages in one orddering group obey strict delivering order,
- which means that messages in an ordering group will be delivered exactly in the order of their arrival at the target queue (FIFO).
- Ordering groups are identified by their string names.</para>
+ <para>
+ Message ordering groups is the JBoss Messaging implementation of strict message ordering. When the ordering group feature is enabled, message priorities no longer have an influence on the order that the messages are delivered. Messages in a particular ordering group will be delivered in the exact order that they arrive at the target queue (FIFO).
+ </para>
- <para>When ordering group is enabled, message priorities will not take any effect on the ordering of the messages. Message ordering groups obey the following rules:</para>
+ <para>
+ Ordering groups are identified by their string names and obey the following rules:
+ </para>
+
+ <formalpara><title>Rule One</title>
+ <para>
+ The messages that form a part of an ordering group are delivered one at a time. The next message will not be delivered until the delivery of a previous message is completed. Message delivery completion is signaled by various means, depending on the acknowledge mode settings;
+ </para>
+ </formalpara>
- <para>Rule 1. Messages in the ordering group are delivered one at a time. Next message will not be delivered until the delivery of previous message is completed.</para>
-
<itemizedlist>
- <listitem><para>For CLIENT_ACKNOWLEDGE mode, the Message.acknowledge() method signals the completion state.</para></listitem>
- <listitem>
- <para>For AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE modes, the completion of the message is identified by either</para>
- <itemizedlist>
- <listitem>
- <para>successful returning from the MessageConsumer.receive() methods</para>
- </listitem>
- <listitem>
- <para>successful returning from the onMessage() call of the MessageListener()</para>
- </listitem>
- </itemizedlist>
+ <listitem>
+ <para>
+ The <varname>CLIENT_ACKNOWLEDGE</varname> mode results in the <classname>Message</classname>.<methodname>acknowledge()</methodname> method signaling the completion state.
+ </para>
</listitem>
+ <listitem>
+ <para>
+ The <varname>AUTO_ACKNOWLEDGE</varname> and <varname>DUPS_OK_ACKNOWLEDGE</varname> modes result in the completion of the message being identified by either of the following;
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ a successful return from one of the <classname>MessageConsumer</classname>.<methodname>receive()</methodname> methods, or
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ a successful return from the <methodname>onMessage()</methodname> call of the <literal>MessageListener()</literal>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
</itemizedlist>
+ <important><title>DupsOKBatchSize</title>
+ <para>
+ It is important to set <varname>DupsOKBatchSize</varname>=<literal>1</literal> on the connection factory when using <varname>DUPS_OK_ACKNOWLEDGE</varname> mode. The default <varname>DupsOKBatchSize</varname> value is <literal>2000</literal> which results in the JMS broker buffering 2000 messages prior to sending them. It is possible that messages will remain stuck in a queue when using StrictMessageOrdering in <varname>DUPS_OK_ACKNOWLEDGE</varname> mode as the second message in a series will not be sent until the previous message is acknowledged. Setting DupsOKBatchSize=1 ensures that the messages are not buffered and acknowledgments are sent following each message.
+ </para>
+ </important>
-
- <para>If the message consumer is closed, the current message processing is deemed to be finished, even if the acknowledge is not called before consumer close.</para>
+ <note><title>Note</title>
+ <para>
+ If the message consumer is closed, the message being processed at the time of its closure will be deemed as completed. This is regardless of whether an <varname>*_ACKNOWLEDGE</varname> is called prior to the closure of the consumer.
+ </para>
+ <!--
+ <para>
+ The current message being processed by a consumer which is subsequently closed will be deemed as completed regardless of whether an <literal>ACKNOWLEDGE</literal> was called prior to closing the consumer.
+ </para>
+ -->
+ </note>
+ <!-- not sure about this. Cannot find in code. -->
- <para>Rule 2. In case of transactional receiving, the next message will not be delivered until the transaction that includes the receiving of the previous message has been committed. If the transaction is rolled back, the previous message will be cancelled back to the JMS server and thus available for the next delivery.
-</para>
+ <formalpara><title>Rule Two</title>
+ <para>
+ In the case of the transactional receipt of messages, the next message will not be delivered until the transaction has been committed. This includes the acknowledgment of the receipt of the current message. If the transaction is rolled back, the message will be canceled, sent back to the JMS server and made available for the next delivery.
+ </para>
+ </formalpara>
<section id="enable.ordering.group">
<title>How to Enable Message Ordering Group</title>
More information about the jboss-cvs-commits
mailing list