[jboss-cvs] JBoss Messaging SVN: r8028 - projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_5_1_0/Messaging_1_4_6/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu May 27 02:58:29 EDT 2010
Author: jaredmorgs
Date: 2010-05-27 02:58:28 -0400 (Thu, 27 May 2010)
New Revision: 8028
Modified:
projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_5_1_0/Messaging_1_4_6/en-US/Configuration.xml
Log:
converted about 20 sections into a varlist
Modified: projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_5_1_0/Messaging_1_4_6/en-US/Configuration.xml
===================================================================
--- projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_5_1_0/Messaging_1_4_6/en-US/Configuration.xml 2010-05-27 06:38:38 UTC (rev 8027)
+++ projects/eap-docs/tags/JBoss_Messaging_User_Guide_EAP_5_1_0/Messaging_1_4_6/en-US/Configuration.xml 2010-05-27 06:58:28 UTC (rev 8028)
@@ -143,175 +143,226 @@
<para>
This section discusses the <literal>ServerPeer</literal> managed bean attributes.
</para>
- <section id="conf.serverpeer.attributes.serverpeerid">
- <title>ServerPeerID</title>
- <para>
+ <variablelist>
+ <varlistentry>
+ <term>ServerPeerID</term>
+ <listitem>
+ <para>
The unique identifier of the <literal>ServerPeer</literal>. Each node deployed must have a unique identifier, whether the nodes form a cluster or are linked by a message bridge. The identifier must be a valid integer.
</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultqueuejndicontext">
- <title>DefaultQueueJNDIContext</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultQueueJNDIContext</term>
+ <listitem>
+ <para>
The default JNDI context to be used when binding queues. The default value is <literal>/queue</literal>.
- </para>
- </section>
- <section id="conf.serverpeer.attributes.defaultopicjndicontext">
- <title>DefaultTopicJNDIContext</title>
- <para>
+</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultTopicJNDIContext</term>
+ <listitem>
+ <para>
The default JNDI context to be used when binding topics. The default value is <literal>/topic</literal>.
- </para>
- </section>
- <section id="conf.serverpeer.attributes.postoffice">
- <title>PostOffice</title>
- <para>
+</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>PostOffice</term>
+ <listitem>
+ <para>
The post office used by the <literal>ServerPeer</literal>. You will not normally need to edit this attribute. The post office routes messages to queues and maintains the mapping between queues and addresses.
</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultdlq">
- <title>DefaultDLQ</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultDLQ</term>
+ <listitem>
+ <para>
The default DLQ (Dead Letter Queue) that the server uses for destinations. You can override the DLQ on a per-destination basis. (For more information, see the configuration information for the destination managed bean.) A DLQ is a destination for messages that the server has failed to deliver more than a certain number of times. If the DLQ is not specified, the message will be removed after the maximum number of delivery attempts. You can specify a global default for the maximum number of delivery attempts with the <varname>DefaultMaxDeliveryAttempts</varname> attribute, or set the maximum individually on a per-destination basis.
</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultmaxdeliveryattempts">
- <title>DefaultMaxDeliveryAttempts</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultMaxDeliveryAttempts</term>
+ <listitem>
+ <para>
The global default for the maximum number of times delivery will be attempted for a message before the message is removed or sent to the DLQ, if configured. The default value is <literal>10</literal>. You can override this value on a per-destination basis.
</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultexpiryqueue">
- <title>DefaultExpiryQueue</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultExpiryQueue</term>
+ <listitem>
+ <para>
The default expiry queue that the <literal>ServerPeer</literal> will use for destinations. You can override this value on a per-destination basis, as seen in the section on destination managed bean configuration. An expiry queue holds messages that have expired. Message expiry is determined by the value of <literal>Message::getJMSExpiration()</literal>. If the expiry queue is not specified, the message will be deleted when it expires.
</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultredliverydelay">
- <title>DefaultRedeliveryDelay</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultRedeliveryDelay</term>
+ <listitem>
+ <para>
This attribute lets you delay a redelivery attempt, which helps to prevent thrashing delivery-failure. The default value is <literal>0</literal> (that is, no delay). You can override this value on a per-destination basis.
</para>
- </section>
- <section id="conf.serverpeer.attributes.messagecountersampleperiod">
- <title>MessageCounterSamplePeriod</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>MessageCounterSamplePeriod</term>
+ <listitem>
+ <para>
This attribute defines the period of time between the server's queries to the queue for queue statistics. The default value is <literal>10000</literal> milliseconds.
</para>
- </section>
- <section id="conf.serverpeer.attributes.failoverstarttimeout">
- <title>FailoverStartTimeout</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>FailoverStartTimeout</term>
+ <listitem>
+ <para>
The longest period (in milliseconds) that the client will wait for failover to begin on the server side when a problem is detected. The default value is <literal>60000</literal> (one minute).
- </para>
- </section>
- <section id="conf.serverpeer.attributes.failovercompletetimeout">
- <title>FailoverCompleteTimeout</title>
- <para>
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>FailoverCompleteTimeout</term>
+ <listitem>
+ <para>
The longest period (in milliseconds) that the client will wait for failover to complete on the server side once failover has been initiated. The default value is <literal>300000</literal> (five minutes).
</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultmessagecounterhistorydaylimit">
- <title>DefaultMessageCounterHistoryDayLimit</title>
- <para>
- JBoss Messaging provides a message counter history, which shows the number of messages arriving on each queue over a certain number of days. This attribute represents the maximum number of days for which to store message counter history. You can override this value on a per-destination.
- </para>
- </section>
- <section id="conf.serverpeer.attributes.clusterpullconnectionfactory">
- <title>ClusterPullConnectionFactory</title>
- <para>
- The connection factory used to pull, or suck, messages between queues. You can omit this attribute to disable message sucking while retaining failover.
- </para>
- </section>
- <section id="conf.serverpeer.attributes.defaultpreserveordering">
- <title>DefaultPreserveOrdering</title>
- <para>
- When <literal>true</literal>, JMS ordering is preserved in the cluster. See the Cluster Configuration section for more detail. The default value is <literal>false</literal>.
- </para>
- </section>
- <section id="conf.serverpeer.attributes.recoverdeliveriestimeout">
- <title>RecoverDeliveriesTimeout</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultMessageCounterHistoryDayLimit</term>
+ <listitem>
+ <para>
+ JBoss Messaging provides a message counter history, which shows the number of messages arriving on each queue over a certain number of days. This attribute represents the maximum number of days for which to store message counter history. You can override this value on a per-destination.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ClusterPullConnectionFactory</term>
+ <listitem>
+ <para>
+ The connection factory used to pull, or suck, messages between queues. You can omit this attribute to disable message sucking while retaining failover.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DefaultPreserveOrdering</term>
+ <listitem>
+ <para>When <literal>true</literal>, JMS ordering is preserved in the cluster. See the Cluster Configuration section for more detail. The default value is <literal>false</literal>.
+</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>RecoverDeliveriesTimeout</term>
+ <listitem>
+ <para>
When failover occurs, messages that have been delivered will be stored while the clients reconnect. If the clients do not reconnect (for example, if the client is dead), these messages will eventually time out and be added to the queue. This attribute sets the period before timeout in milliseconds. The default value is <literal>300000</literal> (five minutes).
</para>
- </section>
- <section id="conf.serverpeer.attributes.enablemessagecounters">
- <title>EnableMessageCounters</title>
- <para>
- When set to <literal>true</literal>, enables message counters upon server start.
- </para>
- </section>
- <section id="conf.serverpeer.attributes.suckerpassword">
- <title>SuckerPassword</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>EnableMessageCounters</term>
+ <listitem>
+ <para>
+ When set to <literal>true</literal>, enables message counters upon server start.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SuckerPassword</term>
+ <listitem>
+ <para>
JBoss Messaging internally creates connections between nodes to redistribute messages between clustered destinations. These connections are created with a special, reserved username. This attribute defines the password to use when creating these connections.
</para>
- <para>
+ <para>
For versions of JBoss Messaging later than 1.4.1.GA, you must define the <varname>SuckerPassword</varname> on the <literal>SecurityMetadataStore</literal>.
</para>
- <warning>
- <para>
+ <warning>
+ <para>
The <varname>SuckerPassword</varname> must be changed at install time, or the default password will be used, giving any user who knows the default password access to any destination on the server.
</para>
- </warning>
- </section>
- <section id="conf.serverpeer.attributes.suckerconnectionretryTimes">
- <title>SuckerConnectionRetryTimes</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 indefinitely".
- </para>
- </section>
- <section id="conf.serverpeer.attributes.suckerconnectionretryinterval">
- <title>SuckerConnectionRetryInterval</title>
- <para>This is the interval in milliseconds between each retry of the failed sucker's
+ </warning>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SuckerConnectionRetryTimes</term>
+ <listitem>
+ <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 indefinitely".</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SuckerConnectionRetryInterval</term>
+ <listitem>
+ <para>This is the interval in milliseconds between each retry of the failed sucker's
connection. The default value is <literal>5000</literal>.</para>
- </section>
- <section id="conf.serverpeer.attributes.stricttck">
- <title>StrictTCK</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>StrictTCK</term>
+ <listitem>
+ <para>
To enable strict JMS Technology Compatibility Kit (TCK) semantics, set this attribute to <literal>true</literal>.
</para>
- </section>
- <section id="conf.serverpeer.attributes.destinations">
- <title>Destinations</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Destinations</term>
+ <listitem>
+ <para>
Returns a list of the destinations (queues and topics) currently deployed.
</para>
- </section>
- <section id="conf.serverpeer.attributes.messagecounters">
- <title>MessageCounters</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>MessageCounters</term>
+ <listitem>
+ <para>
A message counter for a particular queue.
</para>
- </section>
- <section id="conf.serverpeer.attributes.messagestatistics">
- <title>MessageStatistics</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>MessageStatistics</term>
+ <listitem>
+ <para>
Statistics about each message counter for each queue.
</para>
- </section>
- <section id="conf.serverpeer.attributes.supportsfailover">
- <title>SupportsFailover</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SupportsFailover</term>
+ <listitem>
+ <para>
When this attribute is <literal>false</literal>, server-side failover does not occur when a node crashes in a cluster.
</para>
- </section>
- <section id="conf.serverpeer.attributes.persistencemanager">
- <title>PersistenceManager</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>PersistenceManager</term>
+ <listitem>
+ <para>
The persistence manager used by the <literal>ServerPeer</literal>. (You will not normally need to change this attribute.)
</para>
- </section>
- <section id="conf.serverpeer.attributes.jmsusermanager">
- <title>JMSUserManager</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>JMSUserManager</term>
+ <listitem>
+ <para>
The JMS user manager used by the <literal>ServerPeer</literal>. (You will not normally need to change this attribute.)
</para>
- </section>
- <section id="conf.serverpeer.attributes.securitystore">
- <title>SecurityStore</title>
- <para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>SecurityStore</term>
+ <listitem>
+ <para>
The pluggable <literal>SecurityStore</literal>. If you redefine this attribute, remember that you will need to authenticate the <literal>MessageSucker</literal> user (<literal>JBM.SUCKER</literal>) with all special permissions required by clustering.
</para>
- </section>
+ </listitem>
+ </varlistentry>
+ </variablelist>
<section id="conf.serverpeer.operations">
<title>Managed Beans in the ServerPeer</title>
<section id="conf.serverpeer.operations.deployQueue">
More information about the jboss-cvs-commits
mailing list