[jboss-cvs] JBoss Messaging SVN: r8052 - projects/enterprise/EAP/trunk/5.x/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Jun 1 02:28:30 EDT 2010
Author: jaredmorgs
Date: 2010-06-01 02:28:30 -0400 (Tue, 01 Jun 2010)
New Revision: 8052
Modified:
projects/enterprise/EAP/trunk/5.x/en-US/C_Configuration.xml
projects/enterprise/EAP/trunk/5.x/en-US/Configuration.xml
Log:
finished updating chapter 6, and have just started chapter 7.
Modified: projects/enterprise/EAP/trunk/5.x/en-US/C_Configuration.xml
===================================================================
--- projects/enterprise/EAP/trunk/5.x/en-US/C_Configuration.xml 2010-05-31 07:26:12 UTC (rev 8051)
+++ projects/enterprise/EAP/trunk/5.x/en-US/C_Configuration.xml 2010-06-01 06:28:30 UTC (rev 8052)
@@ -1,98 +1,75 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version='1.0' encoding='UTF-8'?>
<chapter id="c_configuration">
- <title>JBoss Messaging Clustering Notes</title>
-
+ <title>Clustering Notes</title>
<section id="c_conf.serverpeerid">
- <title>Unique server peer id</title>
-
- <para>
- In most cases, JBoss Messaging works in a clustered environment with no configuration changes. However, it is crucial that every node is assigned a unique server ID, as specified in the Installation Guide.
+ <title>Unique Server Peer ID</title>
+ <para>In most cases, JBoss Messaging works in a clustered environment with minimal configuration changes. One crucial change that must be made is that every node is assigned a unique server ID, as specified in the Installation Guide.
</para>
<para>
Every deployed node must have a unique ID, including nodes that form a LAN cluster and nodes linked by message bridges.
</para>
</section>
-
<section id="c_conf.clustereddests">
- <title>Clustered destinations</title>
-
+ <title>Clustered Destinations</title>
<para>
JBoss Messaging clusters Java Message Service (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 make a particular destination clustered, set the <varname>clustered</varname> attribute in the destination Deployment Descriptor to <literal>true</literal>.
</para>
<para>
JBoss Messaging balances messages between nodes and caters for consumers of varying speeds so that processing load is distributed efficiently across the cluster.
</para>
-
<para>
To disable message redistribution between nodes while retaining other characteristics of clustered destinations, do not specify the <varname>ClusterPullConnectionFactoryName</varname> attribute on the Server Peer.
</para>
</section>
-
<section id="c_conf.clustereddursubs">
<title>Clustered durable subscriptions</title>
-
<para>
It is also possible to cluster JBoss Messaging durable subscriptions such that multiple subscribers on multiple nodes can consume from one durable subscription. A durable subscription will be clustered if its topic is clustered.
</para>
</section>
-
<section id="c_conf.clusteredtempdest">
<title>Clustered temporary destinations</title>
-
<para>
JBoss Messaging supports clustering of 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>
- Set the <literal>PostOffice</literal>'s <varname>clustered</varname> attribute to <literal>false</literal> if you do not want all nodes to participate in a cluster, or if you do not want the server to be clustered.
+ Set the <literal>PostOffice</literal>'s <varname>clustered</varname> attribute to <literal>false</literal> if you do not want all nodes to participate in a cluster, or if you do not want the server to be clustered.
</para>
</section>
-
<section id="c_conf.orderingincluster">
<title>Message ordering in the cluster</title>
-
<para>
To apply strict JMS ordering to messages such that messages are consumed in the same order they were produced, set the <varname>DefaultPreserveOrdering</varname> Server Peer attribute to <literal>true</literal>. (The default value is <literal>false</literal>.) While set to <literal>true</literal>, messages cannot be distributed as freely around the cluster.
</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 with no exception, then they message has definitely been persisted. However, if an exception is thrown, you cannot be certain that the message was <emphasis>not</emphasis> persisted, because failure may have occurred between the message being persisted and a response being returned to the caller.
</para>
-
<para>
- Your applications must therefore be coded so that its operations are <emphasis>idempotent</emphasis> — that is, they can be repeated without causing the system to become inconsistent.
+ Your applications must therefore be coded so that its operations are <emphasis>idempotent</emphasis> — that is, they can be repeated without causing the system to become inconsistent.
</para>
-
<para>
In a messaging system, you can do this on the application level by checking for duplicate messages and discarding them if the original message has been sent successfully. This <emphasis>duplicate checking</emphasis> is a powerful technique that can remove the need for XA transactions.
</para>
-
<para>
In a clustered environment, JBoss Messaging is configured to perform duplicate checking by default.
</para>
</section>
-
<section id="c_conf.clusteredcfs">
<title>Clustered connection factories</title>
-
<para>
When <varname>supportsLoadBalancing</varname> is set to <literal>true</literal>, consecutive attempts to create connections will round-robin between available servers. The first node is chosen randomly.
</para>
-
<para>
When <varname>supportsFailover</varname> is set to <literal>true</literal>, failover will occur transparently and automatically whenever any connection error is detected.
</para>
-
<para>
If automatic failover is not required, set <varname>supportsFailover</varname> to <literal>false</literal> and provide a standard JMS <literal>ExceptionListener</literal> to be called in case of server failure. Following server failure, you will need to manually close the connection, lookup a new connection factory from HAJNDI, and create a new connection.
</para>
</section>
-</chapter>
\ No newline at end of file
+</chapter>
Modified: projects/enterprise/EAP/trunk/5.x/en-US/Configuration.xml
===================================================================
--- projects/enterprise/EAP/trunk/5.x/en-US/Configuration.xml 2010-05-31 07:26:12 UTC (rev 8051)
+++ projects/enterprise/EAP/trunk/5.x/en-US/Configuration.xml 2010-06-01 06:28:30 UTC (rev 8052)
@@ -1379,7 +1379,7 @@
<varlistentry>
<term>PageSize</term>
<listitem>
- <para> Defines the maximum number of messages that are pre-loaded per operation when loading messages from the queue or subscription. If no value is specified, the default is <literal>2000</literal>.
+ <para>Specifies the maximum number of messages that are pre-loaded per operation when loading messages from the queue or subscription. If no value is specified, the default is <literal>2000</literal>.
</para>
</listitem>
</varlistentry>
@@ -1406,15 +1406,16 @@
<term>RemoveAllMessages</term>
<listitem>
<para>
- Removes (and deletes) all messages from the queue. <emphasis>Use with caution, as this will permanently delete all messages from the queue.</emphasis>
- </para>
+ Removes (and deletes) all messages from the queue. </para>
+ <important>
+ <para>This will permanently delete all messages from the queue; use this operation with caution.</para>
+ </important>
</listitem>
</varlistentry>
<varlistentry>
<term>ListAllMessages</term>
<listitem>
- <para>
- Lists all messages currently in the queue. Using a JMS selector as an argument in this operation lets you retrieve a subset of the messages in the queue that match the given criteria.
+ <para>Lists all messages currently in the queue. Using a JMS selector as an argument in this operation lets you retrieve a subset of the messages in the queue that match the given criteria.
</para>
</listitem>
</varlistentry>
@@ -1447,233 +1448,363 @@
<varlistentry>
<term>ListMessageCounterAsHTML</term>
<listitem>
- <para>Lists the message counter in an easily-displayed HTML format.</para>
+ <para>Lists the message counter in HTML format.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ListMessageCounterHistoryAsHTML</term>
<listitem>
- <para>Lists the message counter history in an easily-displayed HTML format.</para>
+ <para>Lists the message counter history in HTML format.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section id="conf.destination.topic.attributes">
<title>Topic Managed Bean Attributes</title>
- <section id="conf.destination.topic.attributes.name">
- <title>Name</title>
- <para>Defines the name of the topic.</para>
- </section>
- <section id="conf.destination.topic.attributes.jndiName">
- <title>JNDIName</title>
- <para>Defines the JNDI location where the topic is bound.</para>
- </section>
- <section id="conf.destination.topic.attributes.dlq">
- <title>DLQ</title>
- <para>Defines the Dead Letter Queue (DLQ) used for this topic and overrides any value set in the Server Peer configuration file.</para>
- </section>
- <section id="conf.destination.topic.attributes.expiryqueue">
- <title>ExpiryQueue</title>
- <para>Defines the expiry queue used for this topic and overrides any value set in the Server Peer configuration file.</para>
- </section>
- <section id="conf.destination.topic.attributes.redeliverydelay">
- <title>RedeliveryDelay</title>
- <para>Defines the delay period between redelivery attempts for this topic and overrides any value set in the Server Peer configuration file.</para>
- </section>
- <section id="conf.destination.topic.attributes.maxdeliveryattempts">
- <title>MaxDeliveryAttempts</title>
- <para>
+ <variablelist>
+ <varlistentry>
+ <term>Name</term>
+ <listitem>
+ <para>Defines the name of the topic.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>JNDIName</term>
+ <listitem>
+ <para>Defines the JNDI location where the topic is bound.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DLQ</term>
+ <listitem>
+ <para>Defines the Dead Letter Queue (DLQ) used for this topic and overrides any value set in the Server Peer configuration file.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ExpiryQueue</term>
+ <listitem>
+ <para>Defines the expiry queue used for this topic and overrides any value set in the Server Peer configuration file.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>RedeliveryDelay</term>
+ <listitem>
+ <para>Defines the delay period between redelivery attempts for this topic and overrides any value set in the Server Peer configuration file.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>MaxDeliveryAttempts</term>
+ <listitem>
+ <para>
Defines the maximum number of times message delivery will be attempted before the message is sent to the DLQ, if configured. The default value is <literal>-1</literal>, which specifies that the value from the Server Peer configuration file be used. Any other setting overrides the Server Peer value.
</para>
- </section>
- <section id="conf.destination.topic.attributes.security">
- <title>Destination Security Configuration</title>
- <para>
- <literal>SecurityConfig</literal> lets you define which roles can read, write and create on the destination. The syntax matches that of the security configuration in JBossMQ destinations.
- </para>
- <para>
- The <literal>SecurityConfig</literal> element should contain one <literal><security></literal> element, which can contain multiple <literal><role></literal> elements. Each <literal><role></literal> element defines the access type for that particular role.
- </para>
- <para>
- If the <varname>read</varname> attribute is set to <literal>true</literal>, that role has permission to <emphasis>read</emphasis> (create consumers, receive messages, and browse) this destination.
- </para>
- <para>
- If the <varname>write</varname> attribute is set to <literal>true</literal>, that role has permission to <emphasis>write</emphasis> (create producers or send messages) to this destination.</para>
- <para>
- If the <varname>create</varname> attribute is set to <literal>true</literal>, that role has permission to create durable subscriptions on this destination.
- </para>
- <para>
- Configuring security for destinations is optional. If a <literal>SecurityConfig</literal> element is not specified, the default security configuration from the Server Peer will be used.
- </para>
- </section>
- <section id="conf.destination.topic.attributes.paging">
- <title>Destination paging parameters</title>
- <para>
- <emphasis>Pageable Channels</emphasis> is a new feature available in JBoss Messaging.
- </para>
- <para>
- Previously, for an application to support a queue or subscription, the queue needed to be stored entirely in memory. This was not always possible for very large queues or subscriptions.
- </para>
- <para>
- <emphasis>Pageable Channels</emphasis> is a new JBoss Messaging feature that lets you specify a maximum number of messages to be stored in memory at one time, on a queue-by-queue or topic-by-topic basis. JBoss Messaging then pages messages to and from storage transparently in blocks. This allows queues and subscriptions to grow to very large sizes without any degradation in performance as channel size increases. It has been tested with queues in excess of ten million 2 kilobyte messages on very basic hardware, and has the potential to scale to much greater message numbers.
- </para>
- <para>
- The individual parameters associated with pageable channels are as follows:
- </para>
- <para>
- <literal>FullSize</literal> defines the maximum number of messages held by the queue or topic subscription in memory at any one time. The actual queue can hold more messages, but these are paged to and from storage as messages are added or consumed. If no value is specified, the default is <literal>75000</literal>.
- </para>
- <para>
- <literal>PageSize</literal> defines the maximum number of messages that are pre-loaded per operation when loading messages from the queue or subscription. If no value is specified, the default is <literal>2000</literal>.
- </para>
- <para>
- <literal>DownCacheSize</literal> — when messages are paged to storage from the queue, they enter a <emphasis>Down Cache</emphasis> before being written to storage. This enables the write to occur as a single operation, which aids performance. This attribute determines the maximum number of messages that the Down Cache will hold before the messages are flushed to storage. If no value is specified, the default is <literal>2000</literal>.
- </para>
- <para>
- Paging parameters for temporary queues must be specified on the appropriate connection factory. See the section on Connection Factory Configuration for details.
- </para>
- </section>
- <section id="conf.destination.topic.attributes.createdprogrammatically">
- <title>CreatedProgrammatically</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>CreatedProgrammatically</term>
+ <listitem>
+ <para>
Returns <literal>true</literal> if the topic was created programmatically.
</para>
- </section>
- <section id="conf.destination.topic.attributes.maxsize">
- <title>MaxSize</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>MaxSize</term>
+ <listitem>
+ <para>
Specifies the maximum number of messages that can be held in a topic subscription. Any excess messages will be dropped from the topic. The default value is <literal>-1</literal>, which applies no size restriction.
</para>
- </section>
- <section id="conf.destination.topic.attributes.clustered">
- <title>Clustered</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Clustered</term>
+ <listitem>
+ <para>
Set this to <literal>true</literal> if your destination is clustered.
</para>
- </section>
- <section id="conf.destination.topic.attributes.messagecounterhistorydaylimit">
- <title>MessageCounterHistoryDayLimit</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>MessageCounterHistoryDayLimit</term>
+ <listitem>
+ <para>
Defines the maximum number of days to retain message counter history, and overrides any value set in the Server Peer configuration file.</para>
- </section>
- <section id="conf.destination.topic.attributes.messagecounters">
- <title>MessageCounters</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>MessageCounters</term>
+ <listitem>
+ <para>
Returns a list of message counters for the topic's subscriptions.
</para>
- </section>
- <section id="conf.destination.topic.attributes.allmessagecount">
- <title>AllMessageCount</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>AllMessageCount</term>
+ <listitem>
+ <para>
Returns the total number of messages in all subscriptions belonging to the topic.
</para>
- </section>
- <section id="conf.destination.topic.attributes.durablemessagecount">
- <title>DurableMessageCount</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DurableMessageCount</term>
+ <listitem>
+ <para>
Returns the total number of <emphasis>durable</emphasis> messages in all subscriptions belonging to this topic.
</para>
- </section>
- <section id="conf.destination.topic.attributes.nondurablemessagecount">
- <title>NonDurableMessageCount</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>NonDurableMessageCount</term>
+ <listitem>
+ <para>
Returns the total number of <emphasis>non-durable</emphasis> messages in all subscriptions belonging to this topic.
</para>
- </section>
- <section id="conf.destination.topic.attributes.allsubscriptionscount">
- <title>AllSubscriptionsCount</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>AllSubscriptionsCount</term>
+ <listitem>
+ <para>
Returns a count of all subscriptions belonging to this topic.
</para>
- </section>
- <section id="conf.destination.topic.attributes.durablesubscriptionscount">
- <title>DurableSubscriptionsCount</title>
- <para>Returns a count of all durable subscriptions belonging to this topic.</para>
- </section>
- <section id="conf.destination.topic.attributesnon.durablesubscriptionscount">
- <title>NonDurableSubscriptionsCount</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DurableSubscriptionsCount</term>
+ <listitem>
+ <para>Returns a count of all durable subscriptions belonging to this topic.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>NonDurableSubscriptionsCount</term>
+ <listitem>
+ <para>
Returns a count of all non-durable subscriptions belonging to this topic.
</para>
- </section>
- </section>
- <section id="conf.destination.topic.operations">
- <title>Topic Managed Bean Operations</title>
- <section id="conf.destination.topic.operations.removeallmessages">
- <title>RemoveAllMessages</title>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <section id="conf.destination.topic.attributes.security">
+ <title>Destination Security Configuration</title>
<para>
- Removes and deletes all messages from the subscriptions belonging to this topic. <emphasis>Use with caution, as this permanently deletes all messages from the topic.</emphasis>
+ <markup><SecurityConfig></markup> determines which roles can read, write and create upon the destination. It uses the same syntax and semantics as JBossMQ destination security configuration.
</para>
- </section>
- <section id="conf.destination.topic.operations.listallsubscriptions">
- <title>ListAllSubscriptions</title>
- <para>Lists all subscriptions belonging to this topic.</para>
- </section>
- <section id="conf.destination.topic.operations.listdurablesubscriptions">
- <title>ListDurableSubscriptions</title>
- <para>Lists all durable subscriptions belonging to this topic.</para>
- </section>
- <section id="conf.destination.topic.operations.listnondurablesubscriptions">
- <title>ListNonDurableSubscriptions</title>
- <para>Lists all non-durable subscriptions belonging to this topic.</para>
- </section>
- <section id="conf.destination.topic.operations.listallsubscriptionsashtml">
- <title>ListAllSubscriptionsAsHTML</title>
<para>
- Lists all subscriptions belonging to this topic in an easily-displayed HTML format.
+ The <markup><SecurityConfig></markup> element must contain one <markup><security></markup> element, which can contain multiple <markup><role></markup> elements. A <markup><role></markup> element defines the access type for that particular role using the following attributes:
</para>
- </section>
- <section id="conf.destination.topic.operations.listdurablesubscriptionsashtml">
- <title>ListDurableSubscriptionsAsHTML</title>
- <para>
- Lists all durable subscriptions belonging to this topic in an easily-displayed HTML format.
+ <variablelist>
+ <varlistentry>
+ <term>read</term>
+ <listitem>
+ <para>Specifies the role can create consumers, receive messages, and browse the destination.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>write</term>
+ <listitem>
+ <para>Specifies the role can create producers, or send messages to the destination.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>create</term>
+ <listitem>
+ <para>Specifies the role can create durable subscriptions on this destination.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <note>
+ <para>
+ Configuring security for a destination is optional. If a <literal>SecurityConfig</literal> element is not specified, then the default security configuration from the Server Peer will be used instead.
</para>
+ </note>
</section>
- <section id="conf.destination.topic.operations.listnondurablesubscriptionsashtml">
- <title>ListNonDurableSubscriptionsAsHTML</title>
+ <section id="sect-Destination_Paging_Parameters">
+ <title>Destination paging parameters</title>
<para>
- Lists all non-durable subscriptions belonging to this topic in an easily-displayed HTML format.</para>
- </section>
- <section id="conf.destination.topic.operations.listallmessages">
- <title>ListAllMessages</title>
- <para>Lists all messages belonging to a specified subscription. Using a JMS selector as an argument in this operation lets you retrieve a subset of messages in the queue that match the given criteria.</para>
- </section>
- <section id="conf.destination.topic.operations.listnondurablemessages">
- <title>ListNonDurableMessages</title>
- <para>
- Lists all non-durable messages belonging to the specified subscription. Using a JMS selector as an argument in this operation lets you retrieve a subset of messages in the queue that match the given criteria.
+ Previously, for an application to support a queue or subscription, the queue needed to be stored entirely in memory. This was not always possible for very large queues or subscriptions.
</para>
- </section>
- <section id="conf.destination.topic.operations.listdurablemessages">
- <title>ListDurableMessages</title>
+ <para><emphasis>Pageable Channels</emphasis> is a new JBoss Messaging feature that lets you specify a maximum number of messages to be stored in memory at one time, on a queue-by-queue or topic-by-topic basis. JBoss Messaging then pages messages to and from storage transparently in blocks. This allows queues and subscriptions to grow to very large sizes without any degradation in performance as channel size increases. It has been tested with queues in excess of ten million 2 kilobyte messages on very basic hardware, and has the potential to scale to much greater message numbers.
+ </para>
<para>
- Lists all durable messages belonging to the specified subscription. Using a JMS selector as an argument in this operation lets you retrieve a subset of messages in the queue that match the given criteria.
+ The individual parameters associated with pageable channels are as follows:
</para>
+ <variablelist>
+ <varlistentry>
+ <term>FullSize</term>
+ <listitem>
+ <para>Specifies the maximum number of messages held by the queue or topic subscription in memory at any one time. The actual queue can hold more messages, but these are paged to and from storage as messages are added or consumed. If no value is specified, the default is <literal>75000</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>PageSize</term>
+ <listitem>
+ <para>Specifies the maximum number of messages that are pre-loaded per operation when loading messages from the queue or subscription. If no value is specified, the default is <literal>2000</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DownCacheSize</term>
+ <listitem>
+ <para>Specifies the maximum number of messages the Down Cache holds before the messages are flushed to storage. The default value is <literal>2000</literal> messages. </para>
+ <para>When messages are paged to storage from the queue, they enter a <emphasis>Down Cache</emphasis> before being written to storage. This enables the write to occur as a single operation, which aids performance.
+ </para>
+ <note>
+ <para>
+ Paging parameters for temporary queues must be specified on the appropriate connection factory. See the section on Connection Factory Configuration for details.</para>
+ </note>
+ <para>
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</section>
</section>
+ <section id="conf.destination.topic.operations">
+ <title>Topic Managed Bean Operations</title>
+ <variablelist>
+ <varlistentry>
+ <term>RemoveAllMessages</term>
+ <listitem>
+ <para>
+ Removes (and deletes) all messages from subscriptions that belong to this topic. </para>
+ <important>
+ <para>This will permanently delete all messages from the topic; use this operation with caution.</para>
+ </important>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ListAllMessages</term>
+ <listitem>
+ <para>Lists all messages belonging to a specified subscription. Using a JMS selector as an argument in this operation lets you retrieve a subset of messages in the queue that match the given criteria. </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ListDurableMessages</term>
+ <listitem>
+ <para>Lists all durable messages belonging to the specified subscription. Using a JMS selector as an argument in this operation lets you retrieve a subset of messages in the queue that match the given criteria.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ResetMessageCounter</term>
+ <listitem>
+ <para>Resets the message counter to zero.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ResetMessageCounterHistory</term>
+ <listitem>
+ <para>Resets the message counter history.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ListAllSubscriptionsAsHTML</term>
+ <listitem>
+ <para>Lists all subscriptions belonging to this topic in HTML format.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ListDurableSubscriptionsAsHTML</term>
+ <listitem>
+ <para>Lists all durable subscriptions belonging to this topic in HTML format.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ListNonDurableSubscriptions</term>
+ <listitem>
+ <para>Lists all non-durable messages belonging to the specified subscription. Using a JMS selector as an argument in this operation lets you retrieve a subset of messages in the queue that match the given criteria. </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ListNonDurableSubscriptionsAsHTML</term>
+ <listitem>
+ <para>
+ Lists all non-durable subscriptions belonging to this topic in HTML format.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </section>
</section>
</section>
<section id="conf.connectionfactory">
<title>Configuring Connection Factories</title>
<para>
- By default, JBoss Messaging is configured to bind two connection factories in JNDI upon startup.
+ JBoss Messaging is configured by default to bind two connection factories in JNDI upon startup.
</para>
- <para>
- The first connection factory is the default non-clustered connection factory, which is bound into the following JNDI contexts: <literal>/ConnectionFactory</literal>, <literal>/XAConnectionFactory</literal>, <literal>java:/ConnectionFactory</literal>, and <literal>java:/XAConnectionFactory</literal>. This connection factory is provided to maintain compatibility with applications originally written against JBossMQ, which does not include automatic failover or load balancing. If you do not require client-side automatic failover or load balancing, then you should use this first connection factory.
+ <para>The first connection factory is the default, non-clustered connection factory. This connection factory is provided to maintain compatibility with applications originally written against JBossMQ, which does not include automatic failover or load balancing. If you do not require client-side automatic failover or load balancing, then you should use this first connection factory.
</para>
- <para>
- The second connection factory is the default clustered connection factory, which is bound into the following JNDI contexts: <literal>/ClusteredConnectionFactory</literal>, <literal>/ClusteredXAConnectionFactory</literal>, <literal>java:/ClusteredConnectionFactory</literal>, and <literal>java:/ClusteredXAConnectionFactory</literal>.
+ <para>The first connection factory is bound into the following JNDI contexts:</para>
+ <itemizedlist>
+ <listitem>
+ <para><literal>/ConnectionFactory</literal> </para>
+ </listitem>
+ <listitem>
+ <para><literal>/XAConnectionFactory</literal></para>
+ </listitem>
+ <listitem>
+ <para><literal>java:/ConnectionFactory</literal></para>
+ </listitem>
+ <listitem>
+ <para><literal>java:/XAConnectionFactory</literal>.</para>
+ </listitem>
+ </itemizedlist>
+ <para>The second connection factory is the default clustered connection factory, which is bound into the following JNDI contexts:</para>
+ <itemizedlist>
+ <listitem>
+ <para><literal>/ClusteredConnectionFactory</literal></para>
+ </listitem>
+ <listitem>
+ <para><literal>/ClusteredXAConnectionFactory</literal></para>
+ </listitem>
+ <listitem>
+ <para><literal>java:/ClusteredConnectionFactory</literal></para>
+ </listitem>
+ <listitem>
+ <para><literal>java:/ClusteredXAConnectionFactory</literal></para>
+ </listitem>
+ </itemizedlist>
+ <para>You may want to configure additional connection factories if you want to provide a default client ID for a connection factory, or to bind a connection factory to a different JNDI location. To deploy a new connection factory, configure a new <literal>ConnectionFactory</literal> managed bean in <filename>connection-factories-service.xml</filename>.
</para>
<para>
- You may want to configure additional connection factories — for example, if you want to provide a default client ID for a connection factory, or to bind a connection factory to a different JNDI location. To deploy a new connection factory, configure a new <literal>ConnectionFactory</literal> managed bean in <filename>connection-factories-service.xml</filename>.
- </para>
- <para>
You can also create a new service deployment descriptor, <filename><name>-service.xml</filename>, and deploy it in <filename>$JBOSS_HOME/server/messaging/deploy</filename>.
</para>
- <para>
- Enable support for automatic failover or load balancing by setting the relevant attributes in your connection factory:
+ <para>Enable support for automatic failover or load balancing by setting the relevant attributes in your connection factory:
</para>
- <programlisting><![CDATA[
+ <example>
+ <title>Connection Factory</title>
+ <para>This example connection factory creates a connection factory with the preconfigured client ID <literal>myClientID</literal>, which is bound to two locations in the JNDI tree: <literal>/MyConnectionFactory</literal> and <literal>/factories/cf</literal>.</para>
+ <para>The example overrides the following default values: </para>
+ <itemizedlist>
+ <listitem>
+ <para><varname>PreFetchSize</varname></para>
+ </listitem>
+ <listitem>
+ <para><varname>DefaultTempQueueFullSize</varname></para>
+ </listitem>
+ <listitem>
+ <para><varname>DefaultTempQueuePageSize</varname></para>
+ </listitem>
+ <listitem>
+ <para><varname>DefaultTempQueueDownCacheSize</varname></para>
+ </listitem>
+ <listitem>
+ <para><varname>DupsOKBatchSize</varname></para>
+ </listitem>
+ <listitem>
+ <para><varname>SupportsFailover</varname></para>
+ </listitem>
+ <listitem>
+ <para><varname>SupportsLoadBalancing</varname></para>
+ </listitem>
+ <listitem>
+ <para><varname>LoadBalancingFactory</varname></para>
+ </listitem>
+ </itemizedlist>
+ <para>The connection factory uses the default remoting connector. To use a different remoting connector with the connection factory, change the <literal>Connector</literal> attribute to specify the service name of the connector you wish to use.</para>
+ <programlisting language="XML" role="XML"><![CDATA[
<mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
name="jboss.messaging.connectionfactory:service=MyConnectionFactory"
xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
@@ -1719,126 +1850,147 @@
<attribute name="DupsOKBatchSize">10000</attribute>
</mbean>
]]></programlisting>
- <para>
- The example configuration would create a connection factory with the preconfigured client ID <literal>myClientID</literal>, which would be bound to two locations in the JNDI tree: <literal>/MyConnectionFactory</literal> and <literal>/factories/cf</literal>. This connection factory overrides the default values for <varname>PreFetchSize</varname>, <varname>DefaultTempQueueFullSize</varname>, <varname>DefaultTempQueuePageSize</varname>, <varname>DefaultTempQueueDownCacheSize</varname> and <varname>DupsOKBatchSize</varname>, <varname>SupportsFailover</varname>, <varname>SupportsLoadBalancing</varname> and <varname>LoadBalancingFactory</varname>. The connection factory will use the default remoting connector. To use a different remoting connector with the connection factory, change the <literal>Connector</literal> attribute to specify the service name of the connector you wish to use.
- </para>
+ </example>
<section id="conf.connectionfactory.attributes">
<title>ConnectionFactory Managed Bean Attributes</title>
- <section id="conf.connectionfactory.attributes.clientid">
- <title>ClientID</title>
- <para>
- You can preconfigure a connection factory with a client ID. Any connection created via this connection factory will obtain this client ID.
+ <variablelist>
+ <varlistentry>
+ <term>ClientID</term>
+ <listitem>
+ <para>
+ You can preconfigure a connection factory with a client ID. Any connection created via this connection factory will obtain this client ID.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>JNDIBindings</term>
+ <listitem>
+ <para>Lists available JNDI bindings for this connection factory.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>PrefetchSize</term>
+ <listitem>
+ <para>Specifies how many messages the window holds at once, for consumer flow control. The window size determines the number of messages a server can send to a consumer without blocking. Each consumer maintains a buffer of messages from which it consumes.
</para>
- </section>
- <section id="conf.connectionfactory.attributes.jndibindings">
- <title>JNDIBindings</title>
- <para>Lists available JNDI bindings for this connection factory.</para>
- </section>
- <section id="conf.connectionfactory.attributes.prefetchsize">
- <title>PrefetchSize</title>
- <para>
- Specifies how many messages the window holds at once, for consumer flow control. The window size determines the number of messages a server can send to a consumer without blocking. Each consumer maintains a buffer of messages from which it consumes.
+ <para>Transmission Control Protocol (TCP) implements its own additional flow control. Message consumption can also be blocked if the TCP window size is smaller than the <parameter>PrefetchSize</parameter> parameter.
</para>
- <para>
- Transmission Control Protocol (TCP) implements its own additional flow control. Message consumption can also be blocked if the TCP window size is smaller than the PrefetchSize parameter.
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SlowConsumers</term>
+ <listitem>
+ <para>Specifies whether the allowable buffer size for slow consumers is reduced. Reducing the buffer size for slow consumers results in 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>
- <section id="conf.connectionfactory.attributes.slowconsumers">
- <title>SlowConsumers</title>
- <para>
- 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.
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>StrictTck</term>
+ <listitem>
+ <para>Enables strict JMS behavior if the attribute is set to <literal>true</literal>. Strict JMS behavior is required by the Technology Compatibility Kit (TCK).</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SendAcksAsync</term>
+ <listitem>
+ <para>Specifies
+ acknowledgments are sent asynchronously if the attribute is set to <literal>true</literal>. This can improve performance, particularly if <literal>auto_acknowledge</literal> mode is active.
</para>
- </section>
- <section id="conf.connectionfactory.attributes.tckstrictbehavior">
- <title>StrictTck</title>
- <para>When set to <literal>true</literal>, strict JMS behavior (as required by the Technology Compatibility Kit) is enabled.</para>
- </section>
- <section id="conf.connectionfactory.attributes.sendacksasync">
- <title>SendAcksAsync</title>
- <para>
- When set to <literal>true</literal>, acknowledgments are sent asynchronously. This can improve performance, particularly if <literal>auto_acknowledge</literal> mode is active.
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultTempQueueFullSize</term>
+ <listitem>
+ <para>Optional attribute that specifies the paging parameters for temporary full size queue destinations, which are scoped to connections created with this connection factory. The default value is <literal>200000</literal>. For more information about these attributes, refer to <xref linkend="sect-Destination_Paging_Parameters"/>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultTempQueuePageSize</term>
+ <listitem>
+ <para>Optional attribute that specifies the paging parameters for temporary page size destinations, which are scoped to connections created with this connection factory. The default value is <literal>2000</literal>. For more information about these attributes, refer to <xref linkend="sect-Destination_Paging_Parameters"/>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultTempQueueDownCacheSize</term>
+ <listitem>
+ <para>Optional attribute that specifies the paging parameters for temporary down cache size destinations, which are scoped to connections created with this connection factory. The default value is <literal>2000</literal>. For more information about these attributes, refer to <xref linkend="sect-Destination_Paging_Parameters"/>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DupsOKBatchSize</term>
+ <listitem>
+ <para>
+ Specifies the number of <literal>DUPS_OK_ACKNOWLEDGE</literal> acknowledgments that are buffered locally before they are sent. The default value is <literal>2000</literal>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SupportsLoadBalancing</term>
+ <listitem>
+ <para>Specifies whether client-side load balancing is enabled for the connection factory on clustered installations.
+ If load balancing is enabled, any connection created by that connection factory will be load-balanced across the nodes of a cluster. A connection created on a particular node remains on that node.
+ The default value is <literal>false</literal>.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SupportsFailover</term>
+ <listitem>
+ <para>Specifies whether client-side automatic failover is enabled for the connection factory on clustered installations.
+
+ If automatic failover is enabled, JBoss Messaging will automatically and transparently failover to another node in the cluster when a connection problem is detected.
+ The default value is <literal>false</literal>.</para>
+ <note>
+ <para>When automatic failover is disabled, the user code is responsible for catching connection exceptions in synchronous JMS operations, and a JMS <literal>ExceptionListener</literal> must be installed to catch exceptions asynchronously. When an exception is caught, the client-side code must lookup a new connection factory via HAJNDI and recreate the connection.
</para>
- </section>
- <section id="conf.connectionfactory.attributes.tempqueuepaging">
- <title>Temporary queue paging parameters</title>
- <para>
- <varname>DefaultTempQueueFullSize</varname>, <varname>DefaultTempQueuePageSize</varname> and <varname>DefaultTempQueueDownCacheSize</varname> are optional attributes. They determine the default paging parameters used for temporary destinations that are scoped to connections created with this connection factory. See the section on Paging Channels for further information about these values.
+ </note>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DisableRemotingChecks</term>
+ <listitem>
+ <para>Specifies whether the connection factory checks that the corresponding JBoss Remoting Connector uses sensible values. JBoss Messaging is very sensitive to these values, and there is rarely any need to change them. To disable this sanity checking, set <varname>DisableRemotingChecks</varname> to <literal>false</literal>.
</para>
- <para>
- <varname>DefaultTempQueueFullSize</varname> defaults to <literal>200000</literal>.
- </para>
- <para>
- <varname>DefaultTempQueuePageSize</varname> and <varname>DefaultTempQueueDownCacheSize</varname> default to <literal>2000</literal>.
- </para>
- </section>
- <section id="conf.connectionfactory.attributes.dupsokbatchsize">
- <title>DupsOKBatchSize</title>
- <para>
- 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>
- <section id="conf.connectionfactory.attributes.supportsloadbalancing">
- <title>SupportsLoadBalancing</title>
- <para>
- When you use a connection factory with a clustered JBoss Messaging installation, client-side load balancing is determined by the <varname>supportsLoadBalancing</varname> attribute on the connection factory. If load balancing is enabled, any connection created by that connection factory will be load-balanced across the nodes of a cluster. A connection created on a particular node remains on that node.
- </para>
- <para>
- The <varname>LoadBalancingFactory</varname> attribute determines whether connections are load-balanced. The default value is <literal>false</literal>
- </para>
- </section>
- <section id="conf.connectionfactory.attributes.supportsfailover">
- <title>SupportsFailover</title>
- <para>
- When you use a connection factory with a clustered JBoss Messaging installation, automatic failover on the client side is determined by the <varname>supportsFailover</varname> attribute on the connection factory. If automatic failover is enabled, when a connection problem is detected, JBoss Messaging will automatically and transparently failover to another node in the cluster.
- </para>
- <para>
- If automatic failover is not required, set this attribute to <literal>false</literal>. (This is the default value.) When automatic failover is disabled, the user code is responsible for catching connection exceptions in synchronous JMS operations, and a JMS <literal>ExceptionListener</literal> must be installed to catch exceptions asynchronously. When an exception is caught, the client-side code should lookup a new connection factory via HAJNDI and recreate the connection.
- </para>
- </section>
- <section id="conf.connectionfactory.attributes.disableremotingchecks">
- <title>DisableRemotingChecks</title>
- <para>
- By default, when deploying a connection factory, JBoss Messaging checks that the corresponding JBoss Remoting Connector has sensible values. JBoss Messaging is very sensitive to these values, and there is rarely any need to change them. To disable this sanity checking, set <varname>DisableRemotingChecks</varname> to <literal>false</literal> (the default value).
- </para>
- <warning>
- <para>
- There is rarely a good reason to disable checking. Only do so if you are absolutely certain it must be done.
+ <warning>
+ <para>We strongly recommend you do not disable checking. Only do so if you are absolutely certain it must be done.
</para>
- </warning>
- </section>
- <section id="conf.connectionfactory.attributes.loadbalancingfactory">
- <title>LoadBalancingFactory</title>
- <para>
- If your connection factory uses client-side load balancing, you can specify how this is implemented by overriding this attribute. The value must correspond to the name of a class that implements the interface <literal>org.jboss.jms.client.plugin.LoadBalancingFactory</literal>.
+ </warning>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>LoadBalancingFactory</term>
+ <listitem>
+ <para>Specifies the client-side load balancing factory implementation used by the connection factory.
+ The value must correspond to the name of a class that implements the interface <literal>org.jboss.jms.client.plugin.LoadBalancingFactory</literal>.
</para>
- <para>
- The default value is <literal>org.jboss.jms.client.plugin.RoundRobinLoadBalancingFactory</literal>, which load-balances connections across the cluster in a round-robin fashion.
+ <para>The default value is <literal>org.jboss.jms.client.plugin.RoundRobinLoadBalancingFactory</literal>, which load-balances connections across the cluster in a round-robin fashion.
</para>
- </section>
- <section id="conf.connectionfactory.attributes.connector">
- <title>Connector</title>
- <para>
- Specifies the remoting connector used by the connection factory. Different connection factories can use different connectors, so you can deploy one connection factory that uses the HTTP transport to communicate with the server, and another that uses the bisocket transport to communicate.
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Connector</term>
+ <listitem>
+ <para>Specifies the remoting connector used by the connection factory. Different connection factories can use different connectors, so you can deploy one connection factory that uses the HTTP transport to communicate with the server, and another that uses the bisocket transport to communicate.
</para>
- </section>
- <section id="conf.connectionfactory.attributes.enableorderinggroup">
- <title>EnableOrderingGroup</title>
- <para>
- 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>
- <para>
- 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>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>EnableOrderingGroup</term>
+ <listitem>
+ <para>Specifies 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>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultOrderingGroupName</term>
+ <listitem>
+ <para>Specifies the default name for the message ordering group. The specified name 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>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</section>
-<!-- End conf.connectionfactory.attributes --> </section>
-<!-- End conf.connectionfactory --> <section id="conf.connector">
+ </section>
+ <section id="conf.connector">
<title>Configuring the Remoting Connector</title>
<para>
- JBoss Messaging uses JBoss Remoting for all communication between the client and the server. (For further information about JBoss Remoting configuration and capabilities, see the JBoss Remoting documentation.)
+ JBoss Messaging uses JBoss Remoting for all communication between the client and the server. (For further information about JBoss Remoting configuration and capabilities, see the <citetitle>JBoss Remoting</citetitle> documentation.)
</para>
<para>
The default configuration includes one remoting connector, which is used by the single default connection factory. Each connection factory can be configured to use a different connector.
@@ -1847,7 +1999,7 @@
The default connector is configured to use the remoting bisocket transport, a TCP socket-based transport that listens and accepts connections only on the server side. That is, connections are always initiated from the client side. This connector is ideal for typical firewall scenarios, where only inbound connections are allowed on the server, or where only outbound connections are allowed from the client.
</para>
<para>
- The bisocket transport can be configured to use SSL when a higher level of security is required.
+ The bisocket transport can be configured to use SSL when higher security is required.
</para>
<para>
The other supported transport is the HTTP transport, which uses the Hypertext Transfer Protocol to communicate between client and server. The client periodically polls the server for messages to receive data. This transport is ideal when a firewall between server and client allows only incoming HTTP traffic on the server. Because of its polling behavior and the HTTP, this transport does not perform as well as the bisocket transport. It is not designed to handle high-load situations.
@@ -1856,9 +2008,11 @@
No other remoting transports are currently supported by JBoss Messaging.
</para>
<para>
- Remoting configuration details can be seen in <filename>$JBOSS_HOME/server/$SERVER/deploy/messaging/remoting-bisocket-service.xml</filename>. The following code is an example of a bisocket remoting configuration:
+ Remoting configuration details can be seen in <filename><replaceable>$JBOSS_HOME</replaceable>/server/<replaceable>$SERVER</replaceable>/deploy/messaging/remoting-bisocket-service.xml</filename>. The following code is an example of a bisocket remoting configuration:
</para>
-<!-- Addition start here --> <programlisting><![CDATA[
+ <example id="exam-Bisocket_Remoting_Example">
+ <title>Bisocket Remoting Configuration</title>
+ <programlisting><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<!--
@@ -1992,62 +2146,62 @@
</server>
]]></programlisting>
-<!-- Addition ends here --> <para>
- Some attributes should not be changed unless you know exactly what you are doing. Attributes that can be changed include:
+ </example>
+ <para>There are restricted attributes that should not be changed unless you are absolutely confident you understand the impact of the changes. The following attributes are safe to change and configure to the requrements of your project:
</para>
- <itemizedlist>
- <listitem>
- <para>
- <varname>clientLeasePeriod</varname>
- </para>
- <para>
+ <variablelist>
+ <varlistentry>
+ <term>clientLeasePeriod</term>
+ <listitem>
+ <para>
Clients periodically return <emphasis>heartbeats</emphasis> to the server to confirm that they are still active. If the server does not receive a heartbeat after a certain period of time, it will close down the connection and remove all resources that correspond to the client's session. The <varname>clientLeasePeriod</varname> determines the period of time between heartbeats, in milliseconds. The default value is <literal>10000</literal>.
</para>
- <para>
+ <para>
By default, the server closes a client if it does not receive a heartbeat within double the <varname>clientLeasePeriod</varname>. In reality, the period is automatically resized according to system load.
</para>
- </listitem>
- <listitem>
- <para>
- <varname>numberOfRetries</varname>
- </para>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>numberOfRetries</term>
+ <listitem>
+ <para>
The number of seconds JBoss Remoting blocks on the client pool while waiting for a connection to become available. If you have a very large number of sessions concurrently accessing the server from a client and cannot obtain connections from the pool, you may want to increase this value.
</para>
- </listitem>
- <listitem>
- <para>
- <varname>clientMaxPoolSize</varname>
- </para>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>clientMaxPoolSize</term>
+ <listitem>
+ <para>
JBoss Remoting maintains a client-side pool of TCP connections on which to service requests. If you have a large number of sessions concurrently accessing the server from a client and cannot obtain connections from the pool, you may want to increase this value.
</para>
- </listitem>
- <listitem>
- <para>
- <varname>secondaryBindPort</varname>
- </para>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>secondaryBindPort</term>
+ <listitem>
+ <para>
The bisocket transport uses control connections to pass control messages between server and client. This attribute defines the address to which the secondary <literal>ServerSocket</literal> is bound. To work behind a firewall, you may need to specify a particular value for your firewall configuration.
</para>
- </listitem>
- <listitem>
- <para>
- <varname>secondaryConnectPort</varname>
- </para>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>secondaryConnectPort</term>
+ <listitem>
+ <para>
The port that the client uses to connect. Specify this to let your client work with NAT routers.
</para>
- </listitem>
- <listitem>
- <para>
- <varname>maxPoolSize</varname>
- </para>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>maxPoolSize</term>
+ <listitem>
+ <para>
The number of threads used on the server side to service requests.
</para>
- </listitem>
- </itemizedlist>
+ </listitem>
+ </varlistentry>
+ </variablelist>
<para>
By default, JBoss Messaging binds to <literal>${jboss.bind.address}</literal>, which can be defined by running the <command>./run.sh -c <yourconfig> -b yourIP</command> command.
</para>
@@ -2055,12 +2209,11 @@
If necessary, you can change <filename>remoting-bisocket-service.xml</filename> to use a different communication port.
</para>
<warning>
- <para>
- There is rarely a good reason to change values in the bisocket or sslbisocket connector configuration other than those listed previously. Changing other values can cause JBoss Messaging to stop functioning correctly.
+ <para>Do not change values in the bisocket or sslbisocket connector configuration other than those listed above. Changing other values can cause JBoss Messaging to stop functioning correctly.
</para>
</warning>
</section>
-<!-- end conf.connector --> <section id="conf.servicebindingmanager">
+ <section id="conf.servicebindingmanager">
<title>ServiceBindingManager</title>
<para>
The <literal>SeviceBindingManager</literal> provides multiple application server instances running on the same IP using different port ranges, which is useful during development. There are other ways to do this, but the <literal>ServiceBindingManager</literal> removes much hassle.
@@ -2071,8 +2224,5 @@
<para>
If you are using a more recent version of JBoss Messaging in an older version of the JBoss Application Server, the example bindings in the Application Server distribution may be out of date. The relevant sections must therefore be overwritten with the remoting configuration from the JBoss Messaging distribution.
</para>
- <para>
- See the Installation chapter for further information about setting up the <literal>ServiceBindingManager</literal> for JBoss Messaging.
- </para>
</section>
-<!-- End conf.callback --></chapter>
+</chapter>
More information about the jboss-cvs-commits
mailing list