[jboss-cvs] JBoss Messaging SVN: r7991 - projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Mar 30 07:13:47 EDT 2010
Author: laubai
Date: 2010-03-30 07:13:47 -0400 (Tue, 30 Mar 2010)
New Revision: 7991
Modified:
projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/configuration.xml
projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/introduction.xml
projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/ordering_group.xml
Log:
JBPAPP-2059 Updated JBM documentation according to latest community CP10.
Modified: projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/configuration.xml
===================================================================
--- projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/configuration.xml 2010-03-30 03:09:57 UTC (rev 7990)
+++ projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/configuration.xml 2010-03-30 11:13:47 UTC (rev 7991)
@@ -332,10 +332,23 @@
This must be specified at install time, or the default password will be used. Any one who then knows the default password will be able to gain access to any destinations on the server. This value MUST be changed at install time. </para>
</warning>
+ <formalpara id="conf.serverpeer.attributes.suckerconnectionretryTimes">
+ <title>SuckerConnectionRetryTimes</title>
+ <para>Maximum times for a sucker's connection to retry in case of failure.
+ Default is -1 (retry forever)</para>
+ </formalpara>
+
+ <formalpara id="conf.serverpeer.attributes.suckerconnectionretryinterval">
+ <title>SuckerConnectionRetryInterval</title>
+ <para>The interval in milliseconds between each retry of the failed sucker's
+ connection. Default is 5000.</para>
+ </formalpara>
+
+
<formalpara>
<title>StrictTCK</title>
- <para>Set to true if you want strict JMS TCK semantiocs</para>
+ <para>Set to true if you want strict JMS TCK semantics</para>
</formalpara>
<formalpara>
@@ -388,6 +401,15 @@
user ("JBM.SUCKER") with all the special permissions required by
clustering.</para>
</formalpara>
+
+ <formalpara id="conf.serverpeer.attributes.supportstxage">
+ <title>SupportsTxAge</title>
+
+ <para>Controls whether to store transaction creation time. If set to
+ true, transaction creation time will be stored in the transaction record. If set
+ to false, transaction creation time won't be recorded. Default is false.</para>
+ </formalpara>
+
</section>
<section id="conf.serverpeer.operations">
<title>We now discuss the MBean operations of the ServerPeer
@@ -554,8 +576,44 @@
format.</para>
</formalpara>
</section>
+
+
+ <section id="conf.serverpeer.operations.listallpreparedtransactions">
+ <title>ListAllPreparedTransactions</title>
+
+ <para>Display the details of all prepared transactions</para>
+ </section>
+
+ <section id="conf.serverpeer.operations.listpreparedtransactions">
+ <title>ListPreparedTransactions</title>
+
+ <para>Display the details of all prepared transactions whose ages
+ are equal to or older than a certain time.</para>
+ </section>
+
+ <section id="conf.serverpeer.operations.showmessagedetails">
+ <title>ShowMessageDetails</title>
+
+ <para>Display the details of a message. It takes message id as its parameter.</para>
+ </section>
+
+ <section id="conf.serverpeer.operations.commitpreparedtransaction">
+ <title>CommitPreparedTransaction</title>
+
+ <para>Manually commit a prepared transaction. It takes transaction id as its parameter.</para>
+ </section>
+
+ <section id="conf.serverpeer.operations.rollbackpreparedtransaction">
+ <title>RollbackPreparedTransaction</title>
+
+ <para>Manually roll back a prepared transaction. It takes transaction id as its parameter.</para>
+ </section>
+
+
</section>
+
+
<section id="conf.changingds">
<title>Changing the Database</title>
@@ -1623,7 +1681,7 @@
</formalpara>
<formalpara>
- <title>MessageCounterStatistics</title>
+ <title>MessageStatistics</title>
<para>The statistics for the message counter</para>
</formalpara>
@@ -1643,6 +1701,21 @@
</formalpara>
</section>
+ <section id="conf.destination.queue.attributes.dropoldmessageonredeploy">
+ <title>DropOldMessageOnRedeploy</title>
+
+ <para>When you re-deploy a queue service with a clustered attribute different from the one with which it has been
+ previously deployed, all remaining messages in the queue will be deleted after the re-deployment if you set this
+ parameter to true. Otherwise the messages will be reserved. Default is false.</para>
+ <warning>
+ <para>When you re-deploy a destination, you need to shut
+ down all the nodes in the cluster, make proper configuration change and then restart the nodes.
+ Redeploying from a non-clustered queue to a clustered one requires you set the Clustered attribute to true, and
+ add the queue service configuration to each node. Redeploying from a clustered queue to a non-clustered requires
+ you set the Clustered attribute to false in one of the queue configurations and delete all others in the cluster.</para>
+ </warning>
+ </section>
+
<section id="conf.destination.queue.operations">
<title>We now discuss the MBean operations of the Queue MBean</title>
@@ -1921,6 +1994,24 @@
<para>The count of all non durable subscriptions on this
topic</para>
</formalpara>
+
+ <formalpara id="conf.destination.topic.attributes.dropoldmessageonredeploy">
+ <title>DropOldMessageOnRedeploy</title>
+
+ <para>When you re-deploy a topic service with a clustered attribute different from the one with which it has been
+ previously deployed, all remaining messages of its durable subscribers will be deleted after the re-deployment if you set this
+ parameter to true. Otherwise the messages will be reserved. Default is false.
+ </para>
+ </formalpara>
+
+ <warning>
+ <para>When you re-deploy a destination, you need to shut
+ down all the nodes in the cluster, make proper configuration change and then restart the nodes.
+ Redeploying from a non-clustered topic to a clustered one requires you set the Clustered attribute to true, and
+ add the topic service configuration to each node. Redeploying from a clustered topic to a non-clustered one requires
+ you set the Clustered attribute to false in one of the topic configurations and delete all others in the cluster.</para>
+ </warning>
+
</section>
<section id="conf.destination.topic.operations">
@@ -2144,9 +2235,10 @@
<formalpara>
<title>SlowConsumers</title>
- <para>If you have very slow consumers, then you probably want to make
- sure they don't buffer any messages. Since this can prevent them from
- being consumed by faster consumers. Setting this to true is equivalent
+ <para>If you have very slow consumers, then you probably want to reduce
+ the number of messages they buffer so that unnecessary buffering does not
+ prevent the messages from being consumed by faster consumers. The lowest
+ PrefetchSize allowed is 1. Setting SlowConsumers to true is equivalent
to setting PrefetchSize to 1</para>
</formalpara>
Modified: projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/introduction.xml
===================================================================
--- projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/introduction.xml 2010-03-30 03:09:57 UTC (rev 7990)
+++ projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/introduction.xml 2010-03-30 11:13:47 UTC (rev 7991)
@@ -273,4 +273,4 @@
</itemizedlist>
</para>
</section>
-</chapter>
\ No newline at end of file
+</chapter>
Modified: projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/ordering_group.xml
===================================================================
--- projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/ordering_group.xml 2010-03-30 03:09:57 UTC (rev 7990)
+++ projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_4_3_8/en-US/ordering_group.xml 2010-03-30 11:13:47 UTC (rev 7991)
@@ -30,7 +30,7 @@
</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;
+ The <varname>AUTO_ACKNOWLEDGE</varname> <!--and <varname>DUPS_OK_ACKNOWLEDGE</varname>--> mode results in the completion of the message being identified by either of the following:
</para>
<itemizedlist>
<listitem>
@@ -46,9 +46,9 @@
</itemizedlist>
</listitem>
</itemizedlist>
- <important><title>DupsOKBatchSize</title>
+ <important><title>DUPS_OK_ACKNOWLEDGE Mode</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.
+ Ordering Group cannot work with <varname>DUPS_OK_ACKNOWLEDGE</varname> mode unless the batch acknowlegement size is limited to 1 (<varname>DupsOKBatchSize</varname>). 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>
More information about the jboss-cvs-commits
mailing list