[jboss-cvs] JBossAS SVN: r95151 - in projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3: en-US and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Oct 19 19:16:14 EDT 2009
Author: benlc
Date: 2009-10-19 19:16:13 -0400 (Mon, 19 Oct 2009)
New Revision: 95151
Modified:
projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/Makefile
projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Configuration.xml
projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Introduction.xml
projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Ordering_Group.xml
projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Running_Examples.xml
Log:
'Committing changes to reflect version 1.4.6 GA update'
Modified: projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/Makefile
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/Makefile 2009-10-19 23:10:18 UTC (rev 95150)
+++ projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/Makefile 2009-10-19 23:16:13 UTC (rev 95151)
@@ -6,7 +6,7 @@
#OTHER_LANGS = as-IN bn-IN de-DE es-ES fr-FR gu-IN hi-IN it-IT ja-JP kn-IN ko-KR ml-IN mr-IN or-IN pa-IN pt-BR ru-RU si-LK ta-IN te-IN zh-CN zh-TW
# Extra Parameters start here
-
+SHOW_REMARKS=1
# Extra Parameters stop here
COMMON_CONFIG = /usr/share/publican
include $(COMMON_CONFIG)/make/Makefile.common
Modified: projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Configuration.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Configuration.xml 2009-10-19 23:10:18 UTC (rev 95150)
+++ projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Configuration.xml 2009-10-19 23:16:13 UTC (rev 95151)
@@ -3,7 +3,7 @@
<title>Configuration</title>
<para>
- The Java Message Service (JMS) API specifies how a messaging client interacts with a messaging server. How messaging services such as message destinations and connection factories are defined and implemented depends on the JMS provider. JBoss Messaging has its own files for service configutation. <!--If you are migrating services from JBossMQ (or other JMS provider) to JBoss Messaging, you will need to understand those configuration files.-->
+ The Java Message Service (JMS) API specifies how a messaging client interacts with a messaging server. How messaging services such as message destinations and connection factories are defined and implemented depends on the JMS provider. JBoss Messaging has its own files for service configuration. <!--If you are migrating services from JBossMQ (or other JMS provider) to JBoss Messaging, you will need to understand those configuration files.-->
</para>
<para>
@@ -22,7 +22,7 @@
<title>Configuring the ServerPeer</title>
<para>
- The <literal>ServerPeer</literal> is the heart of the JBoss Messaging JMS facade. You can configure its behaviour by altering <filename>messaging-service.xml</filename>.
+ The <literal>ServerPeer</literal> is the heart of the JBoss Messaging JMS facade. You can configure its behavior by altering <filename>messaging-service.xml</filename>.
</para>
<para>
@@ -55,16 +55,16 @@
<attribute name="PostOffice">jboss.messaging:service=PostOffice</attribute>
<!-- The default Dead Letter Queue (DLQ) to use for destinations.
- This can be overridden on a per destinatin basis -->
+ This can be overridden on a per destination basis -->
<attribute name="DefaultDLQ">jboss.messaging.destination:service=Queue,name=DLQ</attribute>
<!-- The default maximum number of times to attempt delivery of a message before sending to the DLQ (if configured).
- This can be overridden on a per destinatin basis -->
+ This can be overridden on a per destination basis -->
<attribute name="DefaultMaxDeliveryAttempts">10</attribute>
- <!-- The default Expiry Queue to use for destinations. This can be overridden on a per destinatin basis -->
+ <!-- The default Expiry Queue to use for destinations. This can be overridden on a per destination basis -->
<attribute name="DefaultExpiryQueue">jboss.messaging.destination:service=Queue,name=ExpiryQueue</attribute>
@@ -273,15 +273,15 @@
</section>
<section id="conf.serverpeer.attributes.suckerconnectionretryTimes">
- <title>SuckerConnectionRetryTimes</title>
+ <title><remark>SuckerConnectionRetryTimes</remark></title>
<para>
- This is the maximum number of times a sucker's connection is permitted to retry in the event of a failure. The default value is <literal>-1</literal> which represents "retry indefinately".
+ This is the maximum number of times a sucker's connection is permitted to retry in the event of a failure. The default value is <literal>-1</literal> which represents "retry indefinitely".
</para>
</section>
<section id="conf.serverpeer.attributes.suckerconnectionretryinterval">
- <title>SuckerConnectionRetryInterval</title>
+ <title><remark>SuckerConnectionRetryInterval</remark></title>
<para>This is the interval in milliseconds between each retry of the failed sucker's
connection. The default value is <literal>5000</literal>.</para>
@@ -312,7 +312,7 @@
</section>
<section id="conf.serverpeer.attributes.messagestatistics">
- <title>MessageStatistics</title>
+ <title><remark>MessageStatistics</remark></title>
<para>
Statistics about each message counter for each queue.
@@ -1342,7 +1342,7 @@
<section id="conf.destination.queue.attributes.messagecount">
<title>MessageCount</title>
- <para>Returns the total number of messages in the queue. That is, the number of messages being scheduled plus the number being delivered, plus the number not being dedlivered.</para>
+ <para>Returns the total number of messages in the queue. That is, the number of messages being scheduled plus the number being delivered, plus the number not being delivered.</para>
</section>
<section id="conf.destination.queue.attributes.scheduledmessagecount">
@@ -1612,7 +1612,7 @@
<title>AllMessageCount</title>
<para>
- Returns the total number of messages in all supscriptions belonging to the topic.
+ Returns the total number of messages in all subscriptions belonging to the topic.
</para>
</section>
@@ -1755,7 +1755,7 @@
</para>
<para>
- Enable support for automatic failover or load balancing by setting the relevant attributes in your connection faactory:
+ Enable support for automatic failover or load balancing by setting the relevant attributes in your connection factory:
</para>
<programlisting>
@@ -1836,10 +1836,10 @@
</section>
<section id="conf.connectionfactory.attributes.slowconsumers">
- <title>SlowConsumers</title>
+ <title><remark>SlowConsumers</remark></title>
<para>
- If a slow consumer maintains a large buffer, it may prevent faster consumers receiving the buffered messages. Totally disabling buffering is not possible, however, setting <varname>SlowConsumers</varname> to <literal>true</literal> is equivalent to setting <varname>PrefetchSize</varname> to <literal>1</literal> which is the lowest possible value available.
+ The allowable buffer size for slow consumers should be minimized to increase the potential for messages to be consumed by faster consumers. It is not possible to totally disable buffering, however, setting the <varname>SlowConsumers</varname> attribute to <literal>true</literal> will reduce the buffer size. Setting this attribute to <literal>true</literal> is equivalent to setting <varname>PrefetchSize</varname> to <literal>1</literal> which is the lowest possible value available.
</para>
</section>
@@ -1853,7 +1853,7 @@
<title>SendAcksAsync</title>
<para>
- When set to <literal>true</literal>, acknowledgements are sent asynchronously. This can improve performance, particularly if <literal>auto_acknowledge</literal> mode is active.
+ When set to <literal>true</literal>, acknowledgments are sent asynchronously. This can improve performance, particularly if <literal>auto_acknowledge</literal> mode is active.
</para>
</section>
@@ -1875,7 +1875,7 @@
<title>DupsOKBatchSize</title>
<para>
- For sessions that use the <literal>DUPS_OK_ACKNOWLEDGE</literal> mode, this setting determines the number of acknowledgements that will be buffered locally before they are sent. The default value is <literal>2000</literal>.
+ For sessions that use the <literal>DUPS_OK_ACKNOWLEDGE</literal> mode, this setting determines the number of acknowledgments that will be buffered locally before they are sent. The default value is <literal>2000</literal>.
</para>
</section>
@@ -1934,18 +1934,18 @@
</section>
<section id="conf.connectionfactory.attributes.enableorderinggroup">
- <title>EnableOrderingGroup</title>
+ <title><remark>EnableOrderingGroup</remark></title>
<para>
- This parameter controls whether strict message ordering is enabled on the <literal>ConnectionFactory</literal>. If set to <literal>true</literal>, the messages sent from producers created from this connection factory become ordering group messages. The default value for this pameter is <literal>false</literal>.
+ This parameter controls whether strict message ordering is enabled on the <literal>ConnectionFactory</literal>. If set to <literal>true</literal>, any messages sent from producers which are created from the enabled connection factory become ordering group messages. The default value for this parameter is <literal>false</literal>.
</para>
</section>
<section id="conf.connectionfactory.attributes.defaultorderinggroupname">
- <title>DefaultOrderingGroupName</title>
+ <title><remark>DefaultOrderingGroupName</remark></title>
<para>
- This is the default name for the message ordering group which will take effect if the <literal>EnableOrderingGroup</literal> parameter is set to <literal>true</literal> . If this attribute is missing, the group name will be generated automatically.
+ This is the default name for the message ordering group which will take effect once the <literal>EnableOrderingGroup</literal> parameter is set to <literal>true</literal> . If this attribute is missing, the group name will be generated automatically.
</para>
</section>
</section>
Modified: projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Introduction.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Introduction.xml 2009-10-19 23:10:18 UTC (rev 95150)
+++ projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Introduction.xml 2009-10-19 23:16:13 UTC (rev 95151)
@@ -19,7 +19,7 @@
</para>
<section id="features">
- <title>JBoss Messaging Features</title>
+ <title><remark>JBoss Messaging Features</remark></title>
<para>JBoss Messaging provides the following features:</para>
@@ -83,8 +83,10 @@
</para>
</listitem>
- <listitem>
+ <listitem>
+ <formalpara><title><remark>1.4.6 Update Here</remark></title>
<para>servlet transport to allow messaging through a dedicated servlet;</para>
+ </formalpara>
</listitem>
@@ -104,10 +106,11 @@
<para>the automatic paging of messages to storage, which lets you use very large queues that would be too large to fit entirely within system memory.</para>
</listitem>
- <listitem>
+ <listitem><formalpara><title><remark>1.4.6 Update Here</remark></title>
<para>
- strict message ordering, which results in messages belonging to a particular message group being delivered according to the order of their arrival at the target queue.
+ strict message ordering which results in messages belonging to a particular message group being delivered according to the order of their arrival at the target queue.
</para>
+ </formalpara>
</listitem>
</itemizedlist>
@@ -163,7 +166,7 @@
<formalpara>
<title>Completely transparent failover</title>
<para>
- When a server fails, your sessions continue exception-free on a new node. This is also completely configurable: if you do not want to implement this failover behaviour, you can disable it and fall back to exceptions being thrown and manually recreating connections on a new node.
+ When a server fails, your sessions continue exception-free on a new node. This is also completely configurable: if you do not want to implement this failover behavior, you can disable it and fall back to exceptions being thrown and manually recreating connections on a new node.
</para>
</formalpara>
</listitem>
@@ -201,27 +204,27 @@
<important>
<para>
- Although JBoss Messaging deployment descriptors are similar to JBoss MQ deployment descriptors, they are <emphasis>not identical</emphasis>, and will require some simple adjustments before they will work with JBoss Mesaging. The database data model is completely different, so JBoss Messaging should not be used with a JBoss MQ data schema, or vice-versa.
+ Although JBoss Messaging deployment descriptors are similar to JBoss MQ deployment descriptors, they are <emphasis>not identical</emphasis>, and will require some simple adjustments before they will work with JBoss Messaging. The database data model is completely different, so JBoss Messaging should not be used with a JBoss MQ data schema, or vice-versa.
</para>
</important>
</section>
<section id="properties">
- <title>System Properties used by JBoss Messaging</title>
+ <title><remark>System Properties used by JBoss Messaging</remark></title>
<section id="properties.supportBytesId">
- <title>support.bytesId</title>
+ <title><remark>support.bytesId</remark></title>
<para>
- This system property controls the default behavior when constructing a <literal>JBossMessage</literal> object from a foreign message object. If this property is set to true, the <literal>JBossMessage</literal> constructor will try to extract the native byte[] correlation ID from the foreign message headers. If set to false, it will use the normal string type <literal>JMSCorrelationID</literal>. This property will default to <literal>true</literal> if not set or when set to something other than <literal>true</literal> or <literal>false</literal>.
+ This system property controls the default behavior when constructing a <literal>JBossMessage</literal> object from a foreign message object. If this property is set to <literal>true</literal>, the <literal>JBossMessage</literal> constructor will try to extract the native byte[] correlation ID from the foreign message headers. If set to <literal>false</literal>, it will use the normal string type <literal>JMSCorrelationID</literal>. This property will default to <literal>true</literal> if not set or when set to something other than <literal>true</literal> or <literal>false</literal>.
</para>
</section>
<section id="properties.retainOldxabehaviour">
- <title>retain.oldxabehaviour</title>
+ <title><remark>retain.oldxabehaviour</remark></title>
<para>
- This system property controls the type of exception thrown by a JMS XAResource in the event that the prepare is called after the connection is broken. If this property is not defined, an <literal>XAException</literal> with a <literal>XA_RBCOMMFAIL</literal> error code will be thrown. Otherwise an <literal>XAException</literal> with an <literal>XA_RETRY</literal> error code will be thrown. It should be noted that JBoss Messaging does not define this property by default.
+ This system property controls the type of exception thrown by a JMS XAResource in the event that the prepare is called after the connection is broken. If this property is not defined, an <literal>XAException</literal> with an <literal>XA_RBCOMMFAIL</literal> error code will be thrown. Otherwise an <literal>XAException</literal> with an <literal>XA_RETRY</literal> error code will be thrown. It should be noted that JBoss Messaging does not define this property by default.
</para>
</section>
Modified: projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Ordering_Group.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Ordering_Group.xml 2009-10-19 23:10:18 UTC (rev 95150)
+++ projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Ordering_Group.xml 2009-10-19 23:16:13 UTC (rev 95151)
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="orderinggroup">
- <title>Enabling JBoss Messaging Ordering Group</title>
+ <title><remark>Enabling JBoss Messaging Ordering Group</remark></title>
<para>
This section describes how to use the JBoss Messaging ordering group feature to achieve strict message ordering.
@@ -14,29 +14,31 @@
Ordering groups are identified by their string names and obey the following rules:
</para>
+ <formalpara><title>Rule One</title>
<para>
- Rule 1. 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.
+ 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>
<itemizedlist>
<listitem>
<para>
- The <literal>CLIENT_ACKNOWLEDGE</literal> mode results in the <classname>Message</classname>.<methodname>acknowledge()</methodname> method signals the completion state.
+ The <literal>CLIENT_ACKNOWLEDGE</literal> mode results in the <classname>Message</classname>.<methodname>acknowledge()</methodname> method signaling the completion state.
</para>
</listitem>
<listitem>
<para>
- The <literal>AUTO_ACKNOWLEDGE</literal> and <literal>DUPS_OK_ACKNOWLEDGE</literal> modes result in the completion of the message being identified by either of the following:
+ The <literal>AUTO_ACKNOWLEDGE</literal> and <literal>DUPS_OK_ACKNOWLEDGE</literal> modes result in the completion of the message being identified by either of the following;
</para>
<itemizedlist>
<listitem>
<para>
- a successful return from the <classname>MessageConsumer</classname>.<methodname>receive()</methodname> method, or
+ 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>;
+ a successful return from the <methodname>onMessage()</methodname> call of the <literal>MessageListener()</literal>.
</para>
</listitem>
</itemizedlist>
@@ -44,58 +46,74 @@
</itemizedlist>
<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 <literal>ACKNOWLEGE</literal> is called prior to the closure of the consumer.
+ </para>
+ <!--
<para>
- If the message consumer is closed, the current message being processed will be deemed as completed regardless of whether the an <literal>ACKNOWLEGE</literal> is called prior to closing the consumer.
- </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. -->
+ <formalpara><title>Rule Two</title>
<para>
- Rule 2. In the case of the transactional receipt of messages, the next message will not be delivered until the transaction has been committed which includes the acknowledgment of the receipt of the current message. If the transaction is rolled back, the message will be cancelled, sent back to the JMS server and made available for the next delivery.
+ In the case of the transactional receipt of messages, the next message will not be delivered until the transaction has been committed which 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>
<para>
- JBoss Messaging ordering groups may be enabled by using the API or by making configuration changes.
+ JBoss Messaging ordering group may be enabled by one of two means. Either using the API or by making configuration changes.
</para>
-
- <formalpara><title>API Implementation</title>
-
+
+ <!-- <formalpara><title>Enabling with the API</title> -->
+ <section id="enablewiththeapi"><title>Enabling with the API</title>
<para>
- To make use of JBoss Messaging's ordering group feature, one has to obtain a <classname>JBossMessageProducer</classname>.
+ To make use of JBoss Messaging's ordering group feature, it is necessary to create a <classname>JBossMessageProducer</classname> as demonstrated in the following code sample:
</para>
- </formalpara>
+ <!-- </formalpara> -->
- <programlisting>
- JBossMessageProducer producer = (JBossMessageProducer)session.createProducer(queue);
- </programlisting>
+ <programlisting>
+ JBossMessageProducer producer=(JBossMessageProducer)session.createProducer(queue);
+ </programlisting>
-<para>JBossMessageProducer provides two methods for starting and ending an ordering group. The are, respectively:</para>
+ <para>Once created, JBossMessageProducer provides two methods for starting and ending an ordering group.</para>
+ <formalpara><title>enableOrderingGroup()</title>
+ <para>
+ The following code sample demonstrates how to create an ordering group with the name <literal>ogrpName</literal>.
+ </para>
+ </formalpara>
- <programlisting>
-public void enableOrderingGroup(String ogrpName) throws JMSException
- </programlisting>
+ <programlisting>
+ public void enableOrderingGroup(String ogrpName) throws JMSException
+ </programlisting>
+ <para>
+ Once called, the producer will send messages on behalf of the ordering group. If a <literal>null</literal> parameter is supplied, the name of the ordering group will be automatically generated. Calling this method more than once will override any previous method calls.
+ </para>
+ <formalpara><title>disableOrderingGroup()</title>
+ <para>
+ The following code samples demonstrates how to stop producing ordering group messages.
+ </para>
+ </formalpara>
+
+ <programlisting>
+ public void disableOrderingGroup() throws JMSException
+ </programlisting>
+ <para>
+ Once called, the producer will stop sending out ordering group messages and resume its default behavior.
+ </para>
+</section>
+<!-- <formalpara><title>Configuration Changes</title> -->
+<section id="Configurationchanges"><title>Configuration Changes</title>
<para>
- This code example creates an ordering group with the name <literal>ogrpName</literal>. Once called, the producer will send messages on behalf of the ordering group. If a <literal>null</literal> parameter is supplied, the name of the ordering group will be automatically generated. Calling this method more than once will override any previous method calls.
-</para>
-
- <programlisting>
-public void disableOrderingGroup() throws JMSException
- </programlisting>
-
-<para>
- This code example demonstrates how to stop producing ordering group messages. Once called, the producer will stop sending out ordering group messages and return to its default behavior.
-</para>
-
- <formalpara><title>Configuration Implementation</title>
-
-<para>
Users can configure a JBoss Messaging connection factory to enable the ordering group feature. To achieve this, two new attributes are added to the factory service configuration file. These are:
</para>
- </formalpara>
+ <!-- </formalpara> -->
<itemizedlist>
<listitem>
<para>
@@ -104,7 +122,7 @@
<itemizedlist>
<listitem>
<para>
- set this property to <literal>true</literal> to enable the ordering group feature. The default is false.
+ set this property to <literal>true</literal> to enable the ordering group feature. The default value for this property is <literal>false</literal>.
</para>
</listitem>
</itemizedlist>
@@ -129,34 +147,41 @@
Once configured to enable the ordering group feature on a connection factory, all messages that are sent from any producers created from the connection factory become ordering group messages.
</para>
</note>
-<para>Example:</para>
+<para>The following factory service configuration file sample demonstrates how to enable the ordering group feature:</para>
<programlisting>
- <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
- name="jboss.messaging.connectionfactory:service=ConnectionFactory"
- xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
- <depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=bisocket</depends>
- <depends>jboss.messaging:service=PostOffice</depends>
+ <mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
+ name="jboss.messaging.connectionfactory:service=ConnectionFactory"
+ xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
+ <depends optional-attribute-name="ServerPeer">
+ jboss.messaging:service=ServerPeer
+ </depends>
+ <depends optional-attribute-name="Connector">
+ jboss.messaging:service=Connector,transport=bisocket
+ </depends>
+ <depends>
+ jboss.messaging:service=PostOffice
+ </depends>
- <attribute name="JNDIBindings">
- <bindings>
- <binding>/MyConnectionFactory</binding>
- <binding>/XAConnectionFactory</binding>
- <binding>java:/MyConnectionFactory</binding>
- <binding>java:/XAConnectionFactory</binding>
- </bindings>
- </attribute>
+ <attribute name="JNDIBindings">
+ <bindings>
+ <binding>/MyConnectionFactory</binding>
+ <binding>/XAConnectionFactory</binding>
+ <binding>java:/MyConnectionFactory</binding>
+ <binding>java:/XAConnectionFactory</binding>
+ </bindings>
+ </attribute>
- <!-- This are the two properties -->
- <attribute name="EnableOrderingGroup">true</attribute>
- <attribute name="DefaultOrderingGroupName">MyOrderingGroup</attribute>
- </mbean>
+ <!-- This are the two properties -->
+ <attribute name="EnableOrderingGroup">true</attribute>
+ <attribute name="DefaultOrderingGroupName">MyOrderingGroup</attribute>
+ </mbean>
</programlisting>
<para>
- The advantage of a configuration implementation is the ease with which message ordering functionality can be achieved without the need for sode changes. LEAVE OUT?
+ The advantage of enabling the ordering group feature by making configuration changes is the ease with which message ordering functionality can be achieved without the need for code changes.
</para>
+</section>
</section>
@@ -169,17 +194,17 @@
<itemizedlist>
<listitem>
<para>
- Queues must be used for use with the ordering group feature as it will not work with topics.
+ Queues must be used with the ordering group feature. The feature will not work with topics.
</para>
</listitem>
<listitem>
<para>
- Ordering group should not be used in conjunction with message selectors and scheduled delivery.
+ The ordering group feature should not be used in conjunction with message selectors and scheduled delivery.
</para>
</listitem>
<listitem>
<para>
- A message is considered completed and the next message will be available for delivery if the original message is dead or has expired. A dead message is moved to the DLQ whereas an expired message is moved to the ExpiryQueue.
+ A message is considered completed, and the next message will be available for delivery, if the original message is dead or has expired. A dead message is moved to the <literal>DLQ</literal> whereas an expired message is moved to the <literal>ExpiryQueue</literal>.
</para>
</listitem>
<listitem>
@@ -189,7 +214,7 @@
</listitem>
<listitem>
<para>
- In the case of a Distributed Queue, the user should use <literal>HASingleton</literal> to ensure that ordering group functions correctly.
+ In the case of a Distributed Queue, the user should use <literal>HASingleton</literal> to ensure that the ordering group feature functions correctly.
</para>
</listitem>
</itemizedlist>
Modified: projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Running_Examples.xml
===================================================================
--- projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Running_Examples.xml 2009-10-19 23:10:18 UTC (rev 95150)
+++ projects/docs/enterprise/5.0/JBoss_Messaging_1.4.3/en-US/Running_Examples.xml 2009-10-19 23:16:13 UTC (rev 95151)
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="examples">
- <title>Running the Examples</title>
+ <title><remark>Running the Examples</remark></title>
<para>
The <filename>/doc/examples/jboss-messaging-examples/</filename> directory contains a set of examples that demonstrate the various aspects of JBoss Messaging at work.
@@ -123,18 +123,22 @@
<varlistentry>
<term><filename>/doc/examples/jboss-messaging-examples/servlet/</filename></term>
<listitem>
+ <formalpara><title><remark>1.4.6 Update Here</remark></title>
<para>
- This example demonstrates how to use servlet transport with JBoss Messaging. It deploys a servlet and a <literal>ConnectionFactory</literal> that uses the servlet transport.
+ This example demonstrates how to use servlet transport with JBoss Messaging. It deploys a servlet and a <literal>ConnectionFactory</literal> which uses the servlet transport.
</para>
+ </formalpara>
</listitem>
</varlistentry>
<varlistentry>
<term><filename>/doc/examples/jboss-messaging-examples/ordering-group/</filename></term>
<listitem>
+ <formalpara><title><remark>1.4.6 Update Here</remark></title>
<para>
This example demonstrates the use of strict message ordering. It uses the JBoss Messaging ordering group API to deliver strictly ordered messages, regardless of the message priority.
</para>
+ </formalpara>
</listitem>
</varlistentry>
@@ -157,10 +161,12 @@
The non-clustered examples expect an instance of JBoss AS to be running with all default settings.
</para>
+ <formalpara><title><remark>1.4.6 Update Here</remark></title>
<para>
- The clustered examples expect that two instances of JBoss AS will be running with ports settings of <literal>ports-01</literal> and <literal>ports-02</literal>.
+ Use of the clustered examples requires two instances of JBoss AS to be running with corresponding port settings of <literal>ports-01</literal> and <literal>ports-02</literal>. The default ports for a particular example can be overidden by editing the <filename>jndi.properties</filename> file in that example's root directory.
</para>
+ </formalpara>
+
- <para>
- You can override the default ports of an example by editing <filename>jndi.properties</filename> in that example's root directory.</para>
+
</chapter>
More information about the jboss-cvs-commits
mailing list