[jboss-cvs] JBoss Messaging SVN: r7012 - trunk/docs/user-manual/en.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue May 26 06:00:40 EDT 2009
Author: ataylor
Date: 2009-05-26 06:00:40 -0400 (Tue, 26 May 2009)
New Revision: 7012
Modified:
trunk/docs/user-manual/en/command-buffering.xml
trunk/docs/user-manual/en/configuration-index.xml
trunk/docs/user-manual/en/message-grouping.xml
trunk/docs/user-manual/en/pre-acknowledge.xml
Log:
more doc updates
Modified: trunk/docs/user-manual/en/command-buffering.xml
===================================================================
--- trunk/docs/user-manual/en/command-buffering.xml 2009-05-26 09:11:46 UTC (rev 7011)
+++ trunk/docs/user-manual/en/command-buffering.xml 2009-05-26 10:00:40 UTC (rev 7012)
@@ -9,13 +9,13 @@
<para>If the client has sent more commands than were received before failover it can replay any
sent commands from its buffer so that the client and server can reconcile their
states.</para>
- <para>The size of this buffer is configured by the <literal>SendWindowSize</literal> parameter,
- when the server has received <literal>SendWindowSize</literal> bytes of commands and
- processed them it will send back a command confirmation to the client, and the client can
- then free up space in the buffer.</para>
+ <para>The size of this buffer is configured by the <literal>ProducerWindowSize</literal>
+ parameter, when the server has received <literal>ProducerWindowSize</literal> bytes of
+ commands and processed them it will send back a command confirmation to the client, and the
+ client can then free up space in the buffer.</para>
<para>If you are using JMS and you're using the JMS service on the server to load your JMS
connection factory instances into JNDI then this parameter can be configured in <literal
- >jbm-jms.xml</literal> using the element <literal>send-window-size</literal> a. If
+ >jbm-jms.xml</literal> using the element <literal>producer-window-size</literal> a. If
you're using JMS but not using JNDI then you can set these values directly on the <literal
>JBossConnectionFactory</literal> instance using the appropriate setter method.</para>
<para>If you're using core you can set these values directly on the <literal
Modified: trunk/docs/user-manual/en/configuration-index.xml
===================================================================
--- trunk/docs/user-manual/en/configuration-index.xml 2009-05-26 09:11:46 UTC (rev 7011)
+++ trunk/docs/user-manual/en/configuration-index.xml 2009-05-26 10:00:40 UTC (rev 7012)
@@ -776,7 +776,8 @@
<entry>null</entry>
</row>
<row>
- <entry>connection-factory.ping-period</entry>
+ <entry><link linkend="dead.connections"
+ >connection-factory.ping-period</link></entry>
<entry>Long</entry>
<entry>The period between ping packets being sent from client to
server.</entry>
@@ -790,7 +791,8 @@
<entry>5 * 60000 ms</entry>
</row>
<row>
- <entry>connection-factory.call-timeout</entry>
+ <entry><link linkend="call-timeout"
+ >connection-factory.call-timeout</link></entry>
<entry>long</entry>
<entry>the time out, in milliseconds, for remote calls</entry>
<entry>30000 ms</entry>
@@ -825,7 +827,8 @@
<entry>-1</entry>
</row>
<row>
- <entry>connection-factory.producer-window-size</entry>
+ <entry><link linkend="command-buffering"
+ >connection-factory.producer-window-size</link></entry>
<entry>int</entry>
<entry>The window size for sending messages</entry>
<entry>1024 * 1024</entry>
@@ -860,13 +863,15 @@
<entry>false</entry>
</row>
<row>
- <entry>connection-factory.auto-group</entry>
+ <entry><link linkend="message-grouping.jmsconfigure"
+ >connection-factory.auto-group</link></entry>
<entry>boolean</entry>
<entry>Whether or not we automatically use message grouping.</entry>
<entry>false</entry>
</row>
<row>
- <entry>connection-factory.pre-acknowledge</entry>
+ <entry><link linkend="pre-acknowledge.configure"
+ >connection-factory.pre-acknowledge</link></entry>
<entry>boolean</entry>
<entry>Whether messages are pre acknowledged by the server before
sending</entry>
@@ -923,20 +928,23 @@
<entry>-1</entry>
</row>
<row>
- <entry>connection-factory.retry-interval</entry>
+ <entry><link linkend="client-reconnection"
+ >connection-factory.retry-interval</link></entry>
<entry>long</entry>
<entry>The time, in milliseconds, retry a connection after
failing</entry>
<entry>2000</entry>
</row>
<row>
- <entry>connection-factory.retry-interval-multiplier</entry>
+ <entry><link linkend="client-reconnection"
+ >connection-factory.retry-interval-multiplier</link></entry>
<entry>double</entry>
<entry>Used in the calculating the retry interval</entry>
<entry>1d</entry>
</row>
<row>
- <entry>connection-factory.reconnect-attempts</entry>
+ <entry><link linkend="client-reconnection"
+ >connection-factory.reconnect-attempts</link></entry>
<entry>int</entry>
<entry>The number of attempts to make at reconnecting</entry>
<entry>0</entry>
@@ -956,26 +964,30 @@
<entry/>
</row>
<row>
- <entry>queue.name (attribute)</entry>
+ <entry><link linkend="using-jms.server.configuration">queue.name
+ (attribute)</link></entry>
<entry>String</entry>
<entry>Unique name of the queue</entry>
<entry/>
</row>
<row>
- <entry>queue.entry</entry>
+ <entry><link linkend="using-jms.server.configuration"
+ >queue.entry</link></entry>
<entry>String</entry>
<entry>Context where the queue will be bound in JNDI. There can be
many.</entry>
<entry/>
</row>
<row>
- <entry>queue.durable</entry>
+ <entry><link linkend="using-jms.server.configuration"
+ >queue.durable</link></entry>
<entry>Boolean</entry>
<entry>Is the queue durable?</entry>
<entry>true</entry>
</row>
<row>
- <entry>queue.filter</entry>
+ <entry><link linkend="using-jms.server.configuration"
+ >queue.filter</link></entry>
<entry>String</entry>
<entry>Optional filter expression for the queue</entry>
<entry/>
@@ -988,13 +1000,15 @@
<entry/>
</row>
<row>
- <entry>topic.name (attribute)</entry>
+ <entry><link linkend="using-jms.server.configuration">topic.name
+ (attribute)</link></entry>
<entry>String</entry>
<entry>Unique name of the topic</entry>
<entry/>
</row>
<row>
- <entry>topic.entry</entry>
+ <entry><link linkend="using-jms.server.configuration"
+ >topic.entry</link></entry>
<entry>String</entry>
<entry>Context where the topic will be bound in JNDI. There can be
many.</entry>
Modified: trunk/docs/user-manual/en/message-grouping.xml
===================================================================
--- trunk/docs/user-manual/en/message-grouping.xml 2009-05-26 09:11:46 UTC (rev 7011)
+++ trunk/docs/user-manual/en/message-grouping.xml 2009-05-26 10:00:40 UTC (rev 7012)
@@ -14,7 +14,7 @@
consumer. If that consumer closes another consumer is chosen and will receive all
messages with the same group id.</para>
</listitem>
- </itemizedlist>
+ </itemizedlist>
<section id="message-grouping.configuring">
<title>Configuring Message Grouping</title>
<para>Message grouping must be enabled in the address-setting configuration by using a
@@ -35,9 +35,11 @@
<title>Using Core API</title>
<para>The property name used to identify the message group is <literal
>"_JBM_GROUP_ID""</literal> (or the constant <literal
- >MessageImpl.HDR_GROUP_ID</literal>).</para>
+ >MessageImpl.HDR_GROUP_ID</literal>). Alternatively, you can set <literal
+ >autogroup</literal> to true on the <literal>SessionFactory</literal> which will pick a
+ random unique id. </para>
</section>
- <section>
+ <section id="message-grouping.jmsconfigure">
<title>Using JMS</title>
<para>The property name used to identify the message group is <literal
>JMSXGroupID</literal>.</para>
@@ -56,6 +58,16 @@
message.setIntProperty("JMSXGroupSeq", 2);
producer.send(message);
</programlisting>
+ <para>Alternatively, you can set <literal>autogroup</literal> to true on the <literal
+ >JBossConnectonFactory</literal> which will pick a random unique id. This can also be
+ set in the <literal>jbm-jms.xml</literal> file like this:</para>
+ <programlisting><connection-factory name="ConnectionFactory">
+ <connector-ref connector-name="netty-connector"/>
+ <entries>
+ <entry name="ConnectionFactory"/>
+ </entries>
+ <autogroup>true</autogroup>
+</connection-factory></programlisting>
</section>
<section>
<title>Example</title>
Modified: trunk/docs/user-manual/en/pre-acknowledge.xml
===================================================================
--- trunk/docs/user-manual/en/pre-acknowledge.xml 2009-05-26 09:11:46 UTC (rev 7011)
+++ trunk/docs/user-manual/en/pre-acknowledge.xml 2009-05-26 10:00:40 UTC (rev 7012)
@@ -26,10 +26,19 @@
<para>An example of a use case for pre-acknowledgement is for stock price update messages. With
these messages it might be reasonable to lose a message in event of crash, since the next
price update message will arrive soon, overriding the previous price. </para>
- <section>
+ <section id="pre-acknowledge.configure">
<title>Using PRE_ACKNOWLEDGE</title>
- <para>To use pre-acknowledgement mode using the JMS API, create a JMS Session with the
- <literal>JBossSession.PRE_ACKNOWLEDGE</literal> constant.</para>
+ <para>This can be configured in the <literal>jbm-jms.xml</literal> file on the <literal
+ >connection factory</literal> like this:</para>
+ <programlisting><connection-factory name="ConnectionFactory">
+ <connector-ref connector-name="netty-connector"/>
+ <entries>
+ <entry name="ConnectionFactory"/>
+ </entries>
+ <pre-acknowledge>true</pre-acknowledge>
+</connection-factory></programlisting>
+ <para>Alternatively use pre-acknowledgement mode using the JMS API, create a JMS Session with
+ the <literal>JBossSession.PRE_ACKNOWLEDGE</literal> constant.</para>
<programlisting>
// messages will be acknowledge on the server *before* being delivered to the client
Session session = connection.createSession(false, JBossSession.PRE_ACKNOWLEDGE);
More information about the jboss-cvs-commits
mailing list