[jboss-cvs] JBoss Messaging SVN: r3151 - trunk/docs/userguide/en/modules.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Sep 27 18:59:16 EDT 2007
Author: clebert.suconic at jboss.com
Date: 2007-09-27 18:59:16 -0400 (Thu, 27 Sep 2007)
New Revision: 3151
Modified:
trunk/docs/userguide/en/modules/about.xml
trunk/docs/userguide/en/modules/bridge.xml
trunk/docs/userguide/en/modules/c_configuration.xml
trunk/docs/userguide/en/modules/configuration.xml
trunk/docs/userguide/en/modules/gettingstarted.xml
trunk/docs/userguide/en/modules/installation.xml
trunk/docs/userguide/en/modules/introduction.xml
trunk/docs/userguide/en/modules/recovery_config.xml
trunk/docs/userguide/en/modules/runningexamples.xml
Log:
http://jira.jboss.com/jira/browse/JBMESSAGING-1044 - internal formating only
Modified: trunk/docs/userguide/en/modules/about.xml
===================================================================
--- trunk/docs/userguide/en/modules/about.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/about.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -1,71 +1,63 @@
+<?xml version="1.0" encoding="UTF-8"?>
<chapter id="about">
+ <title>Introducing JBoss Messaging Release 1.4.0.GA</title>
- <title>Introducing JBoss Messaging Release 1.4.0.GA</title>
+ <para>JBoss Messaging is a high performance JMS provider in the JBoss
+ Enterprise Middleware Stack (JEMS). It is a complete rewrite of JBossMQ, the
+ legacy JBoss JMS provider.</para>
- <para>
- JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack
- (JEMS). It is a complete rewrite of JBossMQ, the legacy JBoss JMS provider.
- </para>
- <para>
- JBoss Messaging will be the default JMS provider in later versions of JBoss Enterprise Application Platform,
- and JBoss Service Integration Platform.
- It will also be the default JMS provider in JBoss Application Server 5, and is the default JMS provider for
- JBoss ESB.
- </para>
-
- <para>
- JBoss Messaging is an integral part of Red Hat's strategy for messaging.
- </para>
+ <para>JBoss Messaging will be the default JMS provider in later versions of
+ JBoss Enterprise Application Platform, and JBoss Service Integration
+ Platform. It will also be the default JMS provider in JBoss Application
+ Server 5, and is the default JMS provider for JBoss ESB.</para>
- <para>
- Compared with JBossMQ, JBoss Messaging offers vastly improved performance in both single node
- and clustered environments.
- </para>
- <para>
- Please see
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingPerformanceResultsPre1_0">this wiki page</ulink>
- for performance benchmarks and <xref linkend="performance"/> on how to generate your own
- performance benchmarks.
- </para>
- <para>
- JBoss Messaging also features a much better modular architecture that
- will allow us to add more features in the future.
- </para>
+ <para>JBoss Messaging is an integral part of Red Hat's strategy for
+ messaging.</para>
- <para>
- JBoss Messaging can be easily installed in JBoss Application Server 4.2 using a few simple steps to
- remove JBoss MQ and replace with JBoss Messaging. Once JBoss Messaging becomes the default JMS provider
- in JBoss Application Server 4.2, there will be no need to do any manual installation.
- </para>
-
- <para>From release 1.4.0.GA onwards JBoss Messaging is designed for JBoss 4.2 only.</para>
-
- <para>
- The procedure of swapping JMS providers is presented in detail in this manual.
- In <xref linkend="installation"/> we discuss how to install and use JBoss Messaging in a
- JBoss AS 4.2 servers. We cover JBoss Messaging-specific configuration options,
- as well as how to run the build-in sanity / performance tests.
- </para>
+ <para>Compared with JBossMQ, JBoss Messaging offers vastly improved
+ performance in both single node and clustered environments.</para>
- <para>
- This guide is work in progress, as new features will be added at a very
- quick pace.
- </para>
- <para>
- Please send your suggestions or comments to the
- <ulink url="http://www.jboss.org/index.html?module=bb&op=viewforum&f=238">JBoss Messaging user forum</ulink>.
- </para>
+ <para>Please see <ulink
+ url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingPerformanceResultsPre1_0">this
+ wiki page</ulink> for performance benchmarks and <xref
+ linkend="performance" /> on how to generate your own performance
+ benchmarks.</para>
- <para> Permanent Team:
- Tim Fox (Project Lead), Clebert Suconic (Core Developer), Andy Taylor (Core Developer)
- </para>
-
- <para>Contributors: Ovidiu Feodorov (Project Founder), Sergey Koshcheyev, Ron Sigal, Madhu Konda, Jay Howell, Tyronne Wickramarathne, Aaron Walker, Adrian Brock, Rajdeep Dua, Tom Elrod, Alex Fu, Juha Lindfors, Alexey Loubyansky, Luc Texier, Scott Stark
- </para>
-
- <para>Messaging support team: Jay Howell, David Boeren, Mike Clark, Tyronne Wickramarathne
- </para>
+ <para>JBoss Messaging also features a much better modular architecture that
+ will allow us to add more features in the future.</para>
- <para>Other thanks to Mark Little and Pete Bennett</para>
+ <para>JBoss Messaging can be easily installed in JBoss Application Server
+ 4.2 using a few simple steps to remove JBoss MQ and replace with JBoss
+ Messaging. Once JBoss Messaging becomes the default JMS provider in JBoss
+ Application Server 4.2, there will be no need to do any manual
+ installation.</para>
-</chapter>
+ <para>From release 1.4.0.GA onwards JBoss Messaging is designed for JBoss
+ 4.2 only.</para>
+
+ <para>The procedure of swapping JMS providers is presented in detail in this
+ manual. In <xref linkend="installation" /> we discuss how to install and use
+ JBoss Messaging in a JBoss AS 4.2 servers. We cover JBoss Messaging-specific
+ configuration options, as well as how to run the build-in sanity /
+ performance tests.</para>
+
+ <para>This guide is work in progress, as new features will be added at a
+ very quick pace.</para>
+
+ <para>Please send your suggestions or comments to the <ulink
+ url="http://www.jboss.org/index.html?module=bb&op=viewforum&f=238">JBoss
+ Messaging user forum</ulink>.</para>
+
+ <para>Permanent Team: Tim Fox (Project Lead), Clebert Suconic (Core
+ Developer), Andy Taylor (Core Developer)</para>
+
+ <para>Contributors: Ovidiu Feodorov (Project Founder), Sergey Koshcheyev,
+ Ron Sigal, Madhu Konda, Jay Howell, Tyronne Wickramarathne, Aaron Walker,
+ Adrian Brock, Rajdeep Dua, Tom Elrod, Alex Fu, Juha Lindfors, Alexey
+ Loubyansky, Luc Texier, Scott Stark</para>
+
+ <para>Messaging support team: Jay Howell, David Boeren, Mike Clark, Tyronne
+ Wickramarathne</para>
+
+ <para>Other thanks to Mark Little and Pete Bennett</para>
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/bridge.xml
===================================================================
--- trunk/docs/userguide/en/modules/bridge.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/bridge.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -1,134 +1,121 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="bridge">
<title>JBoss Messaging Message Bridge Configuration</title>
-
+
<section id="bridge.overview">
- <title>Message bridge overview</title>
+ <title>Message bridge overview</title>
- <para>JBoss Messaging includes a fully functional message bridge.</para>
-
- <para>The function of the bridge is to consume messages from a source queue or topic, and send them to target
- queue or topic, typically on a different server.
- </para>
-
- <para>The source and target servers do not have to be in the same cluster which makes bridging suitable for reliably sending
- messages from one cluster to another, for instance across a WAN.
- </para>
-
- <para>A bridge is deployed inside a JBoss AS instance. The instance can be the same instance as either the source or target server.
- Or could be on a third, separate JBoss AS instance.
- </para>
+ <para>JBoss Messaging includes a fully functional message bridge.</para>
- <para>A bridge is deployed as an MBean inside JBoss AS. Deployment is trivial - just drop the MBean descriptor into
-the deploy directory of a JBoss configuration which contains JBoss Messaging.
- </para>
+ <para>The function of the bridge is to consume messages from a source
+ queue or topic, and send them to target queue or topic, typically on a
+ different server.</para>
- <para>An example in docs/example/bridge demonstrates a simple bridge being deployed in JBoss AS, and moving messages
-from the source to the target destination
- </para>
-
- <para>The bridge can also be used to bridge messages from other non JBoss Messaging JMS servers, as long as they are JMS 1.1 compliant.
- This is as yet untested.
- </para>
-
- <para>The bridge has built in resilience to failure so if the source or target server connetion is lost, e.g. due to network failure.
-
- Then the bridge can retry connecting to the source and/or target until they come back online. When this happens it will resume
- operation as normal.
- </para>
-
- <para>The bridge can be configured with an optional selector, so it will only consume messages matching that selector</para>
-
- <para>It can be configured to consume from a queue or a topic. When it consumes from a topic it can be configured to consume
- using a non durable or durable subscription
- </para>
-
- <para>The bridge can be configured to bridge messages with one of three levels of quality of service, they are:
- </para>
-
- <para>
- <itemizedlist>
- <listitem>
-
- <para>QOS_AT_MOST_ONCE</para>
-
- <para>
- With this QoS mode messages will reach the destination from the source at most once.
- The messages are consumed from the source and acknowledged
- before sending to the destination. Therefore there is a possibility that if failure occurs between
- removing them from the source and them arriving at the destination they could be lost. Hence delivery
- will occur at most once.
- This mode is avilable for both persistent and non persistent messages.
- </para>
- </listitem>
-
- <listitem>
- <para>QOS_DUPLICATES_OK</para>
-
- <para>
- With this QoS mode, the messages are consumed from the source and then acknowledged
- after they have been successfully sent to the destination. Therefore there is a possibility that if
- failure occurs after sending to the destination but before acknowledging them, they could be sent again
- when the system recovers. I.e. the destination might receive duplicates after a failure.
- This mode is available for both persistent and non persistent messages.
- </para>
-
- </listitem>
-
- <listitem>
- <para>QOS_ONCE_AND_ONLY_ONCE</para>
- <para>
- This QoS mode ensures messages will reach the destination from the source once and only once.
- (Sometimes this mode is known as "exactly once").
- If both the source and the destination are on the same JBoss Messaging server instance then this can
- be achieved by sending and acknowledging the messages in the same local transaction.
- If the source and destination are on different servers this is achieved by enlisting the sending and consuming
- sessions in a JTA transaction. The JTA transaction is controlled by JBoss Transactions JTA implementation which
- is a fully recovering transaction manager, thus providing a very high degree of durability.
- If JTA is required then both supplied connection factories need to be XAConnectionFactory implementations.
- This mode is only available for persistent messages.
- This is likely to be the slowest mode since it requires extra persistence for the transaction logging.
- If you require this level of QoS, please be sure to enable XA recovery with JBoss Transactions.
-
- <note>
- For a specific application it may possible to provide once and only once semantics without using the
- QOS_ONCE_AND_ONLY_ONCE QoS level. This can be done by using the QOS_DUPLICATES_OK mode and then checking for
- duplicates at the destination and discarding them. Some JMS servers provide automatic duplicate message detection
- functionality, or this may be possible to implement on the application level by maintaining a cache of received
- message ids on disk and comparing received messages to them. The cache would only be valid
- for a certain period of time so this approach is not as watertight as using QOS_ONCE_AND_ONLY_ONCE but
- may be a good choice depending on your specific application.
- </note>
-
-
- </para>
- </listitem>
-
- </itemizedlist>
-
- </para>
-
- </section>
-
- <section id="bridge.deployment">
+ <para>The source and target servers do not have to be in the same cluster
+ which makes bridging suitable for reliably sending messages from one
+ cluster to another, for instance across a WAN.</para>
- <title>Bridge deployment</title>
-
- <para>A message bridge is easily deployed by dropping the MBean descriptor in the deploy directory of your JBoss AS installation which contains JBoss Messaging</para>
-
- </section>
-
- <section id="bridge.configuration">
+ <para>A bridge is deployed inside a JBoss AS instance. The instance can be
+ the same instance as either the source or target server. Or could be on a
+ third, separate JBoss AS instance.</para>
- <title>Bridge configuration</title>
-
- <para>In this section we describe how to configure the message bridge</para>
+ <para>A bridge is deployed as an MBean inside JBoss AS. Deployment is
+ trivial - just drop the MBean descriptor into the deploy directory of a
+ JBoss configuration which contains JBoss Messaging.</para>
- <para>Here is an example of a message bridge configuration, with all the attributes shown. Note that some are commented
-out for this configuration, since it is not appropriate to specify them all at once. Which ones are specified depends on
-the configuration you want.</para>
+ <para>An example in docs/example/bridge demonstrates a simple bridge being
+ deployed in JBoss AS, and moving messages from the source to the target
+ destination</para>
- <programlisting>
+ <para>The bridge can also be used to bridge messages from other non JBoss
+ Messaging JMS servers, as long as they are JMS 1.1 compliant. This is as
+ yet untested.</para>
+
+ <para>The bridge has built in resilience to failure so if the source or
+ target server connetion is lost, e.g. due to network failure. Then the
+ bridge can retry connecting to the source and/or target until they come
+ back online. When this happens it will resume operation as normal.</para>
+
+ <para>The bridge can be configured with an optional selector, so it will
+ only consume messages matching that selector</para>
+
+ <para>It can be configured to consume from a queue or a topic. When it
+ consumes from a topic it can be configured to consume using a non durable
+ or durable subscription</para>
+
+ <para>The bridge can be configured to bridge messages with one of three
+ levels of quality of service, they are:</para>
+
+ <para><itemizedlist>
+ <listitem>
+ <para>QOS_AT_MOST_ONCE</para>
+
+ <para>With this QoS mode messages will reach the destination from
+ the source at most once. The messages are consumed from the source
+ and acknowledged before sending to the destination. Therefore there
+ is a possibility that if failure occurs between removing them from
+ the source and them arriving at the destination they could be lost.
+ Hence delivery will occur at most once. This mode is avilable for
+ both persistent and non persistent messages.</para>
+ </listitem>
+
+ <listitem>
+ <para>QOS_DUPLICATES_OK</para>
+
+ <para>With this QoS mode, the messages are consumed from the source
+ and then acknowledged after they have been successfully sent to the
+ destination. Therefore there is a possibility that if failure occurs
+ after sending to the destination but before acknowledging them, they
+ could be sent again when the system recovers. I.e. the destination
+ might receive duplicates after a failure. This mode is available for
+ both persistent and non persistent messages.</para>
+ </listitem>
+
+ <listitem>
+ <para>QOS_ONCE_AND_ONLY_ONCE</para>
+
+ <para>This QoS mode ensures messages will reach the destination from
+ the source once and only once. (Sometimes this mode is known as
+ "exactly once"). If both the source and the destination are on the
+ same JBoss Messaging server instance then this can be achieved by
+ sending and acknowledging the messages in the same local
+ transaction. If the source and destination are on different servers
+ this is achieved by enlisting the sending and consuming sessions in
+ a JTA transaction. The JTA transaction is controlled by JBoss
+ Transactions JTA implementation which is a fully recovering
+ transaction manager, thus providing a very high degree of
+ durability. If JTA is required then both supplied connection
+ factories need to be XAConnectionFactory implementations. This mode
+ is only available for persistent messages. This is likely to be the
+ slowest mode since it requires extra persistence for the transaction
+ logging. If you require this level of QoS, please be sure to enable
+ XA recovery with JBoss Transactions. <note>
+ For a specific application it may possible to provide once and only once semantics without using the QOS_ONCE_AND_ONLY_ONCE QoS level. This can be done by using the QOS_DUPLICATES_OK mode and then checking for duplicates at the destination and discarding them. Some JMS servers provide automatic duplicate message detection functionality, or this may be possible to implement on the application level by maintaining a cache of received message ids on disk and comparing received messages to them. The cache would only be valid for a certain period of time so this approach is not as watertight as using QOS_ONCE_AND_ONLY_ONCE but may be a good choice depending on your specific application.
+ </note></para>
+ </listitem>
+ </itemizedlist></para>
+ </section>
+
+ <section id="bridge.deployment">
+ <title>Bridge deployment</title>
+
+ <para>A message bridge is easily deployed by dropping the MBean descriptor
+ in the deploy directory of your JBoss AS installation which contains JBoss
+ Messaging</para>
+ </section>
+
+ <section id="bridge.configuration">
+ <title>Bridge configuration</title>
+
+ <para>In this section we describe how to configure the message
+ bridge</para>
+
+ <para>Here is an example of a message bridge configuration, with all the
+ attributes shown. Note that some are commented out for this configuration,
+ since it is not appropriate to specify them all at once. Which ones are
+ specified depends on the configuration you want.</para>
+
+ <programlisting>
<mbean code="org.jboss.jms.server.bridge.BridgeService"
name="jboss.messaging:service=Bridge,name=TestBridge"
xmbean-dd="xmdesc/Bridge-xmbean.xml">
@@ -206,114 +193,204 @@
</mbean>
</programlisting>
- <para>We will now discuss each attribute</para>
+ <para>We will now discuss each attribute</para>
- <section id="bridge.configuration.sourceproviderloader">
- <title>SourceProviderLoader</title>
- <para>This is the object name of the JMSProviderLoader MBean that the bridge will use to lookup the source connection factory and source destination.</para>
- <para>By default JBoss AS ships with one JMSProviderLoader, deployed in the file <filename>jms-ds.xml</filename> - this is the default local JMSProviderLoader. (This would be in <filename>hajndi-jms-ds.xml</filename> in a clustered configuration)</para>
- <para>If your source destination is on different servers or even correspond to a different, non JBoss JMS provider, then you can deploy another JMSProviderLoader MBean instance which references the remote JMS provider, and reference that from this attribute. The bridge would then use that remote JMS provider to contact the source destination</para>
- <para>Note that if you are using a remote non JBoss Messaging source or target and you wish once and only once delivery then that remote JMS provider must provide a fully functional JMS XA resource implementation that works remotely from the server - it is known that some non JBoss JMS providers do not provide such a resource</para>
- </section>
+ <section id="bridge.configuration.sourceproviderloader">
+ <title>SourceProviderLoader</title>
- <section id="bridge.configuration.targetproviderloader">
- <title>TargetProviderLoader</title>
- <para>This is the object name of the JMSProviderLoader MBean that the bridge will use to lookup the target connection factory and target destination.</para>
- <para>By default JBoss AS ships with one JMSProviderLoader, deployed in the file <filename>jms-ds.xml</filename> - this is the default local JMSProviderLoader. (This would be in <filename>hajndi-jms-ds.xml</filename> in a clustered configuration)</para>
- <para>If your target destination is on a different server or even correspond to a different, non JBoss JMS provider, then you can deploy another JMSProviderLoader MBean instance which references the remote JMS provider, and reference that from this attribute. The bridge would then use that remote JMS provider to contact the target destination</para>
- <para>Note that if you are using a remote non JBoss Messaging source or target and you wish once and only once delivery then that remote JMS provider must provide a fully functional JMS XA resource implementation that works remotely from the server - it is known that some non JBoss JMS providers do not provide such a resource</para>
- </section>
+ <para>This is the object name of the JMSProviderLoader MBean that the
+ bridge will use to lookup the source connection factory and source
+ destination.</para>
- <section id="bridge.configuration.sourcedestinationlookup">
- <title>SourceDestinationLookup</title>
- <para>This is the full JNDI lookup for the source destination using the SourceProviderLoader</para>
- <para>An example would be /queue/mySourceQueue</para>
- </section>
+ <para>By default JBoss AS ships with one JMSProviderLoader, deployed in
+ the file <filename>jms-ds.xml</filename> - this is the default local
+ JMSProviderLoader. (This would be in
+ <filename>hajndi-jms-ds.xml</filename> in a clustered
+ configuration)</para>
- <section id="bridge.configuration.targetdestinationlookup">
- <title>TargetDestinationLookup</title>
- <para>This is the full JNDI lookup for the target destination using the TargetProviderLoader</para>
- <para>An example would be /topic/myTargetTopic</para>
- </section>
+ <para>If your source destination is on different servers or even
+ correspond to a different, non JBoss JMS provider, then you can deploy
+ another JMSProviderLoader MBean instance which references the remote JMS
+ provider, and reference that from this attribute. The bridge would then
+ use that remote JMS provider to contact the source destination</para>
- <section id="bridge.configuration.sourceusername">
- <title>SourceUsername</title>
- <para>This optional attribute is for when you need to specify the username for creating the source connection</para>
- </section>
+ <para>Note that if you are using a remote non JBoss Messaging source or
+ target and you wish once and only once delivery then that remote JMS
+ provider must provide a fully functional JMS XA resource implementation
+ that works remotely from the server - it is known that some non JBoss
+ JMS providers do not provide such a resource</para>
+ </section>
- <section id="bridge.configuration.sourcepassword">
- <title>SourcePassword</title>
- <para>This optional attribute is for when you need to specify the password for creating the source connection</para>
- </section>
+ <section id="bridge.configuration.targetproviderloader">
+ <title>TargetProviderLoader</title>
- <section id="bridge.configuration.targetusername">
- <title>TargetUsername</title>
- <para>This optional attribute is for when you need to specify the username for creating the target connection</para>
- </section>
+ <para>This is the object name of the JMSProviderLoader MBean that the
+ bridge will use to lookup the target connection factory and target
+ destination.</para>
- <section id="bridge.configuration.targetpassword">
- <title>TargetPassword</title>
- <para>This optional attribute is for when you need to specify the password for creating the target connection</para>
- </section>
+ <para>By default JBoss AS ships with one JMSProviderLoader, deployed in
+ the file <filename>jms-ds.xml</filename> - this is the default local
+ JMSProviderLoader. (This would be in
+ <filename>hajndi-jms-ds.xml</filename> in a clustered
+ configuration)</para>
- <section id="bridge.configuration.qualityofservicemode">
- <title>QualityOfServiceMode</title>
- <para>This integer represents the desired quality of service mode</para>
- <para>Possible values are:
- <itemizedlist>
- <listitem>QOS_AT_MOST_ONCE = 0</listitem>
- <listitem>QOS_DUPLICATES_OK = 1</listitem>
- <listitem>QOS_ONCE_AND_ONLY_ONCE = 2</listitem>
- </itemizedlist>
- </para>
- <para>Please see <xref linkend="bridge.overview"/> for an explanation of what these mean.</para>
- </section>
+ <para>If your target destination is on a different server or even
+ correspond to a different, non JBoss JMS provider, then you can deploy
+ another JMSProviderLoader MBean instance which references the remote JMS
+ provider, and reference that from this attribute. The bridge would then
+ use that remote JMS provider to contact the target destination</para>
- <section id="bridge.configuration.selector">
- <title>Selector</title>
- <para>This optional attribute can contain a JMS selector expression used for consuming messages from the source destination. Only messages that match the selector expression will be bridged from the source to the target destination</para>
- <para>Please note it is always more performant to apply selectors on source topic subscriptions to source queue consumers.</para>
- <para>The selector expression must follow the JMS selector syntax specified here:
-<ulink url="http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html"/></para>
- </section>
+ <para>Note that if you are using a remote non JBoss Messaging source or
+ target and you wish once and only once delivery then that remote JMS
+ provider must provide a fully functional JMS XA resource implementation
+ that works remotely from the server - it is known that some non JBoss
+ JMS providers do not provide such a resource</para>
+ </section>
- <section id="bridge.configuration.maxbatchsize">
- <title>MaxBatchSize</title>
- <para>This attribute specifies the maximum number of messages to consume from the source destination before
-sending them in a batch to the target destination. It's value must >= 1</para>
- </section>
+ <section id="bridge.configuration.sourcedestinationlookup">
+ <title>SourceDestinationLookup</title>
- <section id="bridge.configuration.maxbatchtime">
- <title>MaxBatchTime</title>
- <para>This attribute specifies the maximum number of milliseconds to wait before sending a batch to target, even if the number of messages consumed has not reached MaxBatchSize. It's value must can be -1 to represent 'wait forever', or >=1 to specify an actual time.</para>
- </section>
+ <para>This is the full JNDI lookup for the source destination using the
+ SourceProviderLoader</para>
- <section id="bridge.configuration.subname">
- <title>SubName</title>
- <para>If the source destination represents a topic, and you want to consume from the topic using a durable subscription then this attribute represents the durable subscription name</para>
- </section>
+ <para>An example would be /queue/mySourceQueue</para>
+ </section>
- <section id="bridge.configuration.clientid">
- <title>ClientID</title>
- <para>If the source destination represents a topic, and you want to consume from the topic using a durable subscription then this attribute represents the the JMS client ID to use when creating/looking up the durable subscription</para>
- </section>
+ <section id="bridge.configuration.targetdestinationlookup">
+ <title>TargetDestinationLookup</title>
- <section id="bridge.configuration.failureretryinterval">
- <title>FailureRetryInterval</title>
- <para>This represents the amount of time in ms to wait between trying to recreate connections to the source or target servers when the bridge has detected they have failed</para>
- </section>
-
- <section id="bridge.configuration.maxretries">
- <title>MaxRetries</title>
- <para>This represents the number of times to attempt to recreate connections to the source or target servers when the bridge has detected they have failed. The bridge will give up after trying this number of times. -1 represents 'try forever'</para>
- </section>
+ <para>This is the full JNDI lookup for the target destination using the
+ TargetProviderLoader</para>
- <section id="bridge.configuration.addmessageidinheader">
- <title>AddMessageIDInHeader</title>
- <para>If true, then the original message's message id will appended in the message sent to the destination in the header JBossMessage.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST. If the message is bridged more than once each message-id will be appended.
-This enables a distributed request-response pattern to be used</para>
- </section>
-
- </section>
+ <para>An example would be /topic/myTargetTopic</para>
+ </section>
-</chapter>
+ <section id="bridge.configuration.sourceusername">
+ <title>SourceUsername</title>
+
+ <para>This optional attribute is for when you need to specify the
+ username for creating the source connection</para>
+ </section>
+
+ <section id="bridge.configuration.sourcepassword">
+ <title>SourcePassword</title>
+
+ <para>This optional attribute is for when you need to specify the
+ password for creating the source connection</para>
+ </section>
+
+ <section id="bridge.configuration.targetusername">
+ <title>TargetUsername</title>
+
+ <para>This optional attribute is for when you need to specify the
+ username for creating the target connection</para>
+ </section>
+
+ <section id="bridge.configuration.targetpassword">
+ <title>TargetPassword</title>
+
+ <para>This optional attribute is for when you need to specify the
+ password for creating the target connection</para>
+ </section>
+
+ <section id="bridge.configuration.qualityofservicemode">
+ <title>QualityOfServiceMode</title>
+
+ <para>This integer represents the desired quality of service mode</para>
+
+ <para>Possible values are: <itemizedlist>
+ <listitem>
+ QOS_AT_MOST_ONCE = 0
+ </listitem>
+
+ <listitem>
+ QOS_DUPLICATES_OK = 1
+ </listitem>
+
+ <listitem>
+ QOS_ONCE_AND_ONLY_ONCE = 2
+ </listitem>
+ </itemizedlist></para>
+
+ <para>Please see <xref linkend="bridge.overview" /> for an explanation
+ of what these mean.</para>
+ </section>
+
+ <section id="bridge.configuration.selector">
+ <title>Selector</title>
+
+ <para>This optional attribute can contain a JMS selector expression used
+ for consuming messages from the source destination. Only messages that
+ match the selector expression will be bridged from the source to the
+ target destination</para>
+
+ <para>Please note it is always more performant to apply selectors on
+ source topic subscriptions to source queue consumers.</para>
+
+ <para>The selector expression must follow the JMS selector syntax
+ specified here: <ulink
+ url="http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Message.html"></ulink></para>
+ </section>
+
+ <section id="bridge.configuration.maxbatchsize">
+ <title>MaxBatchSize</title>
+
+ <para>This attribute specifies the maximum number of messages to consume
+ from the source destination before sending them in a batch to the target
+ destination. It's value must >= 1</para>
+ </section>
+
+ <section id="bridge.configuration.maxbatchtime">
+ <title>MaxBatchTime</title>
+
+ <para>This attribute specifies the maximum number of milliseconds to
+ wait before sending a batch to target, even if the number of messages
+ consumed has not reached MaxBatchSize. It's value must can be -1 to
+ represent 'wait forever', or >=1 to specify an actual time.</para>
+ </section>
+
+ <section id="bridge.configuration.subname">
+ <title>SubName</title>
+
+ <para>If the source destination represents a topic, and you want to
+ consume from the topic using a durable subscription then this attribute
+ represents the durable subscription name</para>
+ </section>
+
+ <section id="bridge.configuration.clientid">
+ <title>ClientID</title>
+
+ <para>If the source destination represents a topic, and you want to
+ consume from the topic using a durable subscription then this attribute
+ represents the the JMS client ID to use when creating/looking up the
+ durable subscription</para>
+ </section>
+
+ <section id="bridge.configuration.failureretryinterval">
+ <title>FailureRetryInterval</title>
+
+ <para>This represents the amount of time in ms to wait between trying to
+ recreate connections to the source or target servers when the bridge has
+ detected they have failed</para>
+ </section>
+
+ <section id="bridge.configuration.maxretries">
+ <title>MaxRetries</title>
+
+ <para>This represents the number of times to attempt to recreate
+ connections to the source or target servers when the bridge has detected
+ they have failed. The bridge will give up after trying this number of
+ times. -1 represents 'try forever'</para>
+ </section>
+
+ <section id="bridge.configuration.addmessageidinheader">
+ <title>AddMessageIDInHeader</title>
+
+ <para>If true, then the original message's message id will appended in
+ the message sent to the destination in the header
+ JBossMessage.JBOSS_MESSAGING_BRIDGE_MESSAGE_ID_LIST. If the message is
+ bridged more than once each message-id will be appended. This enables a
+ distributed request-response pattern to be used</para>
+ </section>
+ </section>
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/c_configuration.xml
===================================================================
--- trunk/docs/userguide/en/modules/c_configuration.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/c_configuration.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -1,31 +1,47 @@
+<?xml version="1.0" encoding="UTF-8"?>
<chapter id="c_configuration">
+ <title>JBoss Messaging Clustering Configuration</title>
- <title>JBoss Messaging Clustering Configuration</title>
+ <para>JBoss Messaging clustering should work out of the box in most cases
+ with no configuration changes. It is however crucial that every node in the
+ cluster is assigned a unique server id, as specified in the installation
+ guide.</para>
- <para>
- JBoss Messaging clustering should work out of the box in most cases with no configuration changes. It is however crucial that every node in the cluster is assigned a unique server id, as specified in the installation guide.
- </para>
+ <para>JBoss Messaging clusters 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 designate that a particular destination is
+ clustered simply set the clustered attribute in the destination deployment
+ descriptor to true.</para>
- <para>JBoss Messaging clusters 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 designate that a particular destination is clustered simply set the clustered attribute in the destination deployment descriptor to true.
- </para>
+ <para>JBoss Messaging balances messages between nodes, catering for faster
+ or slower consumers to efficiently balance processing load across the
+ cluster.</para>
- <para>
-JBoss Messaging balances messages between nodes, catering for faster or slower consumers to efficiently balance processing load across the cluster.
- </para>
+ <para>With JBoss Messaging durable subscrtiptions can also be clustered.
+ This means multiple subscribers can consume from the same durable
+ subscription from different nodes of the cluster. A durable subscription
+ will be clustered if it's topic is clustered</para>
- <para>With JBoss Messaging durable subscrtiptions can also be clustered. This means multiple subscribers can consume from the same durable subscription from different nodes of the cluster. A durable subscription will be clustered if it's topic is clustered
- </para>
+ <para>JBoss Messaging also supports clustered temporary topics and queues.
+ All temporary topics and queues will be clustered if the post office is
+ clustered</para>
- <para>JBoss Messaging also supports clustered temporary topics and queues. All temporary topics and queues will be clustered if the post office is clustered
- </para>
+ <para>If you don't want your nodes to participate in a cluster, or only have
+ one non clustered server you can set the clustered attribute on the
+ postoffice to false</para>
- <para>If you don't want your nodes to participate in a cluster, or only have one non clustered server you can set the clustered attribute on the postoffice to false
- </para>
+ <para>If you wish to apply strict JMS ordering to messages, such that a
+ particular JMS consumer consumes messages in the same order as they were
+ produced by a particular producer, you can set the DefaultPreserveOrdering
+ attribute in the server peer to true. By default this is false. The
+ side-effect of setting this to true is that messages cannot be distributed
+ as freely around the cluster</para>
- <para>If you wish to apply strict JMS ordering to messages, such that a particular JMS consumer consumes messages in the same order as they were produced by a particular producer, you can set the DefaultPreserveOrdering attribute in the server peer to true. By default this is false. The side-effect of setting this to true is that messages cannot be distributed as freely around the cluster
- </para>
-
- <para>When pulling reliable messages from one node to another, by default JBoss Messaging uses an XA transaction to ensure that message was removed from one node and added to another transactionally. Using XA transactions is a fairly heavyweight operation. If you are willing to to relax the reliability guarantee somewhat in order to gain some performance then you can set the attribute UseXAForMessagePull in server peer to false. By default it is true
- </para>
-
-</chapter>
+ <para>When pulling reliable messages from one node to another, by default
+ JBoss Messaging uses an XA transaction to ensure that message was removed
+ from one node and added to another transactionally. Using XA transactions is
+ a fairly heavyweight operation. If you are willing to to relax the
+ reliability guarantee somewhat in order to gain some performance then you
+ can set the attribute UseXAForMessagePull in server peer to false. By
+ default it is true</para>
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/configuration.xml
===================================================================
--- trunk/docs/userguide/en/modules/configuration.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/configuration.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -1,54 +1,50 @@
+<?xml version="1.0" encoding="UTF-8"?>
<chapter id="configuration">
- <title>Configuration</title>
+ <title>Configuration</title>
- <para>
- The JMS API specifies how a messaging client interacts with a messaging server. The exact
- definition and implementation of messaging services, such as message destinations and
- connection factories, are specific to JMS providers. JBoss Messaging has its own
- configuration files to configure services. If you are migrating services from JBossMQ
- (or other JMS provider) to JBoss Messaging, you will need to understand those
- configuration files.
- </para>
+ <para>The JMS API specifies how a messaging client interacts with a
+ messaging server. The exact definition and implementation of messaging
+ services, such as message destinations and connection factories, are
+ specific to JMS providers. JBoss Messaging has its own configuration files
+ to configure services. If you are migrating services from JBossMQ (or other
+ JMS provider) to JBoss Messaging, you will need to understand those
+ configuration files.</para>
- <para>
- In this chapter, we discuss how to configure various services inside JBoss Messaging,
- which work together to provide JMS API level services to client applications.
- </para>
+ <para>In this chapter, we discuss how to configure various services inside
+ JBoss Messaging, which work together to provide JMS API level services to
+ client applications.</para>
- <para>
- The JBoss Messaging service configuration is spread among
- several configuration files.
- Depending on the functionality provided by the services it configures, the configuration
- data is distributed between
- <filename>messaging-service.xml</filename>,
- <filename>remoting-bisocket-service.xml</filename>,
- <filename>xxx-persistence-service.xml</filename>
- <filename>connection-factories-service.xml</filename> and
- <filename>destinations-service.xml</filename>.
- </para>
+ <para>The JBoss Messaging service configuration is spread among several
+ configuration files. Depending on the functionality provided by the services
+ it configures, the configuration data is distributed between
+ <filename>messaging-service.xml</filename>,
+ <filename>remoting-bisocket-service.xml</filename>,
+ <filename>xxx-persistence-service.xml</filename>
+ <filename>connection-factories-service.xml</filename> and
+ <filename>destinations-service.xml</filename>.</para>
- <para>
- The AOP client-side and server-side interceptor stacks are configured in
- <filename>aop-messaging-client.xml</filename> and <filename>aop-messaging-server.xml</filename>.
- Normally you will not want to change them, but some of the interceptors can be removed
- to give a small performance increase, if you don't need them. Be very careful you have considered the security implications before removing the
- security interceptor.
- </para>
+ <para>The AOP client-side and server-side interceptor stacks are configured
+ in <filename>aop-messaging-client.xml</filename> and
+ <filename>aop-messaging-server.xml</filename>. Normally you will not want to
+ change them, but some of the interceptors can be removed to give a small
+ performance increase, if you don't need them. Be very careful you have
+ considered the security implications before removing the security
+ interceptor.</para>
- <section id="conf.serverpeer">
- <title>Configuring the ServerPeer</title>
+ <section id="conf.serverpeer">
+ <title>Configuring the ServerPeer</title>
- <para>
- The Server Peer is the heart of the JBoss Messaging JMS facade. The server's configuration,
- resides in <filename>messaging-service.xml</filename> configuration file.
- </para>
+ <para>The Server Peer is the heart of the JBoss Messaging JMS facade. The
+ server's configuration, resides in
+ <filename>messaging-service.xml</filename> configuration file.</para>
- <para>All JBoss Messaging services are rooted at the server peer</para>
+ <para>All JBoss Messaging services are rooted at the server peer</para>
- <para>An example of a Server Peer configuration is presented below. Note that not all values for the server peer's attributes are
- specified in the example</para>
+ <para>An example of a Server Peer configuration is presented below. Note
+ that not all values for the server peer's attributes are specified in the
+ example</para>
- <programlisting>
+ <programlisting>
<mbean code="org.jboss.jms.server.ServerPeer"
name="jboss.messaging:service=ServerPeer"
xmbean-dd="xmdesc/ServerPeer-xmbean.xml">
@@ -167,518 +163,491 @@
</mbean>
</programlisting>
- <section id="conf.serverpeer.attributes">
-
- <title>ServerPeer attributes</title>
+ <section id="conf.serverpeer.attributes">
+ <title>ServerPeer attributes</title>
- <para>
- We now discuss the MBean attributes of the ServerPeer MBean.
- </para>
+ <para>We now discuss the MBean attributes of the ServerPeer
+ MBean.</para>
- <section id="conf.serverpeer.attributes.serverpeerid">
- <title>ServerPeerID</title>
+ <section id="conf.serverpeer.attributes.serverpeerid">
+ <title>ServerPeerID</title>
- <para>
- The unique id of the server peer. Each node in the cluster must have a unique name.
- </para>
- </section>
+ <para>The unique id of the server peer. Each node in the cluster must
+ have a unique name.</para>
+ </section>
- <section id="conf.serverpeer.attributes.defaultqueuejndicontext">
- <title>DefaultQueueJNDIContext</title>
+ <section id="conf.serverpeer.attributes.defaultqueuejndicontext">
+ <title>DefaultQueueJNDIContext</title>
- <para>
- The default JNDI context to use when binding queues. Defaults to /queue.
- </para>
- </section>
+ <para>The default JNDI context to use when binding queues. Defaults to
+ /queue.</para>
+ </section>
- <section id="conf.serverpeer.attributes.defaultopicjndicontext">
- <title>DefaultTopicJNDIContext</title>
+ <section id="conf.serverpeer.attributes.defaultopicjndicontext">
+ <title>DefaultTopicJNDIContext</title>
- <para>
- The default JNDI context to use when binding topics. Defaults to /topic.
- </para>
- </section>
-
+ <para>The default JNDI context to use when binding topics. Defaults to
+ /topic.</para>
+ </section>
- <section id="conf.serverpeer.attributes.postoffice">
- <title>PostOffice</title>
+ <section id="conf.serverpeer.attributes.postoffice">
+ <title>PostOffice</title>
- <para>
- This is the post office that the ServerPeer uses. You will not normally need to change this attribute.
- The post office is responsible for routing messages to queues and maintaining the mapping between addresses and queues.
- </para>
- </section>
+ <para>This is the post office that the ServerPeer uses. You will not
+ normally need to change this attribute. The post office is responsible
+ for routing messages to queues and maintaining the mapping between
+ addresses and queues.</para>
+ </section>
- <section id="conf.serverpeer.attributes.securitydomain">
- <title>SecurityDomain</title>
+ <section id="conf.serverpeer.attributes.securitydomain">
+ <title>SecurityDomain</title>
- <para>
- The JAAS security domain to be used by this server peer
- </para>
- </section>
+ <para>The JAAS security domain to be used by this server peer</para>
+ </section>
<section id="conf.serverpeer.attributes.defaultsecurity">
- <title>DefaultSecurityConfig</title>
+ <title>DefaultSecurityConfig</title>
- <para>
- Default security configuration is used when the security configuration for a specific
- queue or topic has not been overridden in the destination's deployment descriptor.
- It has exactly the same syntax and semantics as in JBossMQ.
- </para>
+ <para>Default security configuration is used when the security
+ configuration for a specific queue or topic has not been overridden in
+ the destination's deployment descriptor. It has exactly the same
+ syntax and semantics as in JBossMQ.</para>
- <para>
- The <literal>DefaultSecurityConfig</literal> attribute element should contain
- one <literal><security></literal> element.
- The <literal><security></literal> element can contain multiple
- <literal><role></literal> elements. Each <literal><role></literal>
- element defines the default access for that particular role.
- </para>
+ <para>The <literal>DefaultSecurityConfig</literal> attribute element
+ should contain one <literal><security></literal> element. The
+ <literal><security></literal> element can contain multiple
+ <literal><role></literal> elements. Each
+ <literal><role></literal> element defines the default access for
+ that particular role.</para>
- <para>
- If the <literal>read</literal> attribute is <literal>true</literal> then that role
- will be able to read (create consumers, receive messaages or browse) destinations
- by default.
- </para>
+ <para>If the <literal>read</literal> attribute is
+ <literal>true</literal> then that role will be able to read (create
+ consumers, receive messaages or browse) destinations by
+ default.</para>
- <para>
- If the <literal>write</literal> attribute is <literal>true</literal> then that role
- will be able to write (create producers or send messages) to destinations by default.
- </para>
+ <para>If the <literal>write</literal> attribute is
+ <literal>true</literal> then that role will be able to write (create
+ producers or send messages) to destinations by default.</para>
- <para>
- If the <literal>create</literal> attribute is <literal>true</literal> then that role
- will be able to create durable subscriptions on topics by default.
- </para>
+ <para>If the <literal>create</literal> attribute is
+ <literal>true</literal> then that role will be able to create durable
+ subscriptions on topics by default.</para>
</section>
<section id="conf.serverpeer.attributes.defaultdlq">
- <title>DefaultDLQ</title>
+ <title>DefaultDLQ</title>
- <para>
- This is the name of the default DLQ (Dead Letter Queue) the server peer will use for destinations. The DLQ can be overridden on a per
- destination basis - see the destination MBean configuration for more details.
+ <para>This is the name of the default DLQ (Dead Letter Queue) the
+ server peer will use for destinations. The DLQ can be overridden on a
+ per destination basis - see the destination MBean configuration for
+ more details. A DLQ is a special destination where messages are sent
+ when the server has attempted to deliver them unsuccessfully more than
+ a certain number of times. If the DLQ is not specified at all then the
+ message will be removed after the maximum number of delivery attempts.
+ The maximum number of delivery attempts can be specified using the
+ attribute DefaultMaxDeliveryAttempts for a global default or
+ individually on a per destination basis.</para>
+ </section>
- A DLQ is a special destination where messages are sent when the server has attempted to deliver them unsuccessfully more than a certain number of
- times.
+ <section id="conf.serverpeer.attributes.defaultmaxdeliveryattempts">
+ <title>DefaultMaxDeliveryAttempts</title>
- If the DLQ is not specified at all then the message will be removed after the maximum number of delivery attempts.
+ <para>The default for the maximum number of times delivery of a
+ message will be attempted before sending the message to the DLQ, if
+ configured.</para>
- The maximum number of delivery attempts can be specified using the attribute DefaultMaxDeliveryAttempts for a global default or individually
- on a per destination basis.
+ <para>The default value is <literal>10</literal>.</para>
- </para>
+ <para>This value can also be overridden on a per destination
+ basis.</para>
</section>
- <section id="conf.serverpeer.attributes.defaultmaxdeliveryattempts">
- <title>DefaultMaxDeliveryAttempts</title>
+ <section id="conf.serverpeer.attributes.defaultexpiryqueue">
+ <title>DefaultExpiryQueue</title>
- <para>
- The default for the maximum number of times delivery of a message will be attempted before sending the message to the DLQ, if configured.
- </para>
- <para>
- The default value is <literal>10</literal >.
- </para>
- <para>This value can also be overridden on a per destination basis.</para>
+ <para>This is the name of the default expiry queue the server peer
+ will use for destinations. The expiry can be overridden on a per
+ destination basis - see the destination MBean configuration for more
+ details. An expiry queue is a special destination where messages are
+ sent when they have expired. Message expiry is determined by the value
+ of Message::getJMSExpiration() If the expiry queue is not specified at
+ all then the message will be removed after it is expired.</para>
</section>
- <section id="conf.serverpeer.attributes.defaultexpiryqueue">
- <title>DefaultExpiryQueue</title>
+ <section id="conf.serverpeer.attributes.defaultredliverydelay">
+ <title>DefaultRedeliveryDelay</title>
- <para>
- This is the name of the default expiry queue the server peer will use for destinations. The expiry can be overridden on a per
- destination basis - see the destination MBean configuration for more details.
+ <para>When redelivering a message after failure of previous delivery
+ it is often beneficial to introduce a delay perform redelivery in
+ order to prevent thrashing of delivery-failure, delivery-failure
+ etc</para>
- An expiry queue is a special destination where messages are sent when they have expired. Message expiry is determined by the value of
- Message::getJMSExpiration()
+ <para>The default value is <literal>0</literal> which means there will
+ be no delay.</para>
- If the expiry queue is not specified at all then the message will be removed after it is expired.
-
- </para>
+ <para>Change this if your application could benefit with a delay
+ before redelivery. This value can also be overridden on a per
+ destination basis.</para>
</section>
- <section id="conf.serverpeer.attributes.defaultredliverydelay">
- <title>DefaultRedeliveryDelay</title>
-
- <para>
- When redelivering a message after failure of previous delivery it is often beneficial to introduce a delay perform redelivery in order
- to prevent thrashing of delivery-failure, delivery-failure etc
- </para>
- <para>
- The default value is <literal>0</literal> which means there will be no delay.
- </para>
- <para>Change this if your application could benefit with a delay before redelivery.
- This value can also be overridden on a per destination basis.
- </para>
- </section>
-
<section id="conf.serverpeer.attributes.messagecountersampleperiod">
- <title>MessageCounterSamplePeriod</title>
+ <title>MessageCounterSamplePeriod</title>
- <para>
- Periodically the server will query each queue to gets its statistics. This is the period.
- </para>
- <para>
- The default value is <literal>10000</literal> milliseconds.
- </para>
+ <para>Periodically the server will query each queue to gets its
+ statistics. This is the period.</para>
+
+ <para>The default value is <literal>10000</literal>
+ milliseconds.</para>
</section>
<section id="conf.serverpeer.attributes.failoverstarttimeout">
- <title>FailoverStartTimeout</title>
+ <title>FailoverStartTimeout</title>
- <para>
- The maximum number of milliseconds the client will wait for failover to start on the server side when a problem is detected.
- </para>
- <para>
- The default value is <literal>60000</literal> (one minute).
- </para>
+ <para>The maximum number of milliseconds the client will wait for
+ failover to start on the server side when a problem is
+ detected.</para>
+ <para>The default value is <literal>60000</literal> (one
+ minute).</para>
</section>
<section id="conf.serverpeer.attributes.failovercompletetimeout">
- <title>FailoverCompleteTimeout</title>
+ <title>FailoverCompleteTimeout</title>
- <para>
- The maximum number of milliseconds the client will wait for failover to complete on the server side after it has started.
- </para>
- <para>
- The default value is <literal>300000</literal> (five minutes).
- </para>
+ <para>The maximum number of milliseconds the client will wait for
+ failover to complete on the server side after it has started.</para>
+
+ <para>The default value is <literal>300000</literal> (five
+ minutes).</para>
</section>
-
<section id="conf.serverpeer.attributes.defaultmessagecounterhistorydaylimit">
- <title>DefaultMessageCounterHistoryDayLimit</title>
+ <title>DefaultMessageCounterHistoryDayLimit</title>
- <para>
- JBoss Messaging provides a message counter history which shows the number of messages arriving on each queue of a certain number of
- days. This attribute represents the maxiumum number of days for which to store message counter history. It can be overridden on a per
- destination basis.
- </para>
+ <para>JBoss Messaging provides a message counter history which shows
+ the number of messages arriving on each queue of a certain number of
+ days. This attribute represents the maxiumum number of days for which
+ to store message counter history. It can be overridden on a per
+ destination basis.</para>
</section>
<section id="conf.serverpeer.attributes.clusterpullconnectionfactory">
- <title>ClusterPullConnectionFactory</title>
+ <title>ClusterPullConnectionFactory</title>
- <para>
- The name of the connection factory to use for pulling messages between nodes. You will not normally need to change this.
- </para>
+ <para>The name of the connection factory to use for pulling messages
+ between nodes. You will not normally need to change this.</para>
</section>
<section id="conf.serverpeer.attributes.usexaformessagepull">
- <title>UseXAForMessagePull</title>
+ <title>UseXAForMessagePull</title>
- <para>
- If true, then move a reliable message from one node to another in an XA transaction. Relaxing this gives better performance at the expense of some reliability. See the cluster configurations section for more details. Default is true.
- </para>
+ <para>If true, then move a reliable message from one node to another
+ in an XA transaction. Relaxing this gives better performance at the
+ expense of some reliability. See the cluster configurations section
+ for more details. Default is true.</para>
</section>
<section id="conf.serverpeer.attributes.defaultpreserveordering">
- <title>DefaultPreserveOrdering</title>
+ <title>DefaultPreserveOrdering</title>
- <para>
- If true, then strict JMS ordering is preserved in the cluster. See the cluster configurations section for more details. Default is false.
- </para>
- </section>
+ <para>If true, then strict JMS ordering is preserved in the cluster.
+ See the cluster configurations section for more details. Default is
+ false.</para>
+ </section>
<section id="conf.serverpeer.attributes.recoverdeliveriestimeout">
- <title>RecoverDeliveriesTimeout</title>
+ <title>RecoverDeliveriesTimeout</title>
- <para>
- When failover occurs, already delivered messages will be kept aside, waiting for clients to reconnect. In the case that clients never reconnect (e.g. the client is dead) then eventually these messages will timeout and be added back to the queue. The value is in ms. The default is 5 mins.
- </para>
+ <para>When failover occurs, already delivered messages will be kept
+ aside, waiting for clients to reconnect. In the case that clients
+ never reconnect (e.g. the client is dead) then eventually these
+ messages will timeout and be added back to the queue. The value is in
+ ms. The default is 5 mins.</para>
</section>
<section id="conf.serverpeer.attributes.suckerpassword">
- <title>SuckerPassword</title>
+ <title>SuckerPassword</title>
- <para>
- For clustering. JBoss Messaging internally makes connections between nodes in order to redistribute messages.
- These connections are made with the user name of a special reserved user.
- The password used by that user is specified by this parameter.
- <warning>This must be specified at install time, or the default password will be used. Any one who then knows
- the default password will be able to gain access to any destinations on the server.</warning>
- </para>
+ <para>For clustering. JBoss Messaging internally makes connections
+ between nodes in order to redistribute messages. These connections are
+ made with the user name of a special reserved user. The password used
+ by that user is specified by this parameter. <warning>
+ This must be specified at install time, or the default password will be used. Any one who then knows the default password will be able to gain access to any destinations on the server.
+ </warning></para>
</section>
<section id="conf.serverpeer.attributes.destinations">
- <title>Destinations</title>
+ <title>Destinations</title>
- <para>
- Returns a list of the destinations (queues and topics) currently deployed.
- </para>
+ <para>Returns a list of the destinations (queues and topics) currently
+ deployed.</para>
</section>
<section id="conf.serverpeer.attributes.messagecounters">
- <title>MessageCounters</title>
+ <title>MessageCounters</title>
- <para>
- JBoss Messaging provides a message counter for each queue.
- </para>
+ <para>JBoss Messaging provides a message counter for each
+ queue.</para>
</section>
<section id="conf.serverpeer.attributes.messagecounterstatistics">
- <title>MessageCountersStatistics</title>
+ <title>MessageCountersStatistics</title>
- <para>
- JBoss Messaging provides statistics for each message counter for each queue.
- </para>
+ <para>JBoss Messaging provides statistics for each message counter for
+ each queue.</para>
</section>
<section id="conf.serverpeer.attributes.supportsfailover">
- <title>SupportsFailover</title>
+ <title>SupportsFailover</title>
- <para>
- Set to false to prevent server side failover occurring in a cluster when a node crashes.
- </para>
+ <para>Set to false to prevent server side failover occurring in a
+ cluster when a node crashes.</para>
</section>
-
-
<section id="conf.serverpeer.attributes.persistencemanager">
- <title>PersistenceManager</title>
+ <title>PersistenceManager</title>
- <para>
- This is the persistence manager that the ServerPeer uses. You will not normally need to change this attribute.
- </para>
+ <para>This is the persistence manager that the ServerPeer uses. You
+ will not normally need to change this attribute.</para>
</section>
<section id="conf.serverpeer.attributes.jmsusermanager">
- <title>JMSUserManager</title>
+ <title>JMSUserManager</title>
- <para>
- This is the JMS user manager that the ServerPeer uses. You will not normally need to change this attribute.
- </para>
+ <para>This is the JMS user manager that the ServerPeer uses. You will
+ not normally need to change this attribute.</para>
</section>
-
<section id="conf.serverpeer.operations">
+ <title>We now discuss the MBean operations of the ServerPeer
+ MBean.</title>
- <title>
- We now discuss the MBean operations of the ServerPeer MBean.
- </title>
+ <section id="conf.serverpeer.operations.deployQueue">
+ <title>DeployQueue</title>
- <section id="conf.serverpeer.operations.deployQueue">
- <title>DeployQueue</title>
+ <para>This operation lets you programmatically deploy a
+ queue.</para>
- <para>
- This operation lets you programmatically deploy a queue.
- </para>
+ <para>There are two overloaded versions of this operation</para>
- <para>There are two overloaded versions of this operation</para>
+ <para>If the queue already exists but is undeployed it is deployed.
+ Otherwise it is created and deployed.</para>
- <para>If the queue already exists but is undeployed it is deployed. Otherwise it is created and deployed.</para>
+ <para>The <literal>name</literal> parameter represents the name of
+ the destination to deploy.</para>
- <para>The <literal>name</literal> parameter represents the name of the destination to deploy.</para>
- <para>The <literal>jndiName</literal> parameter (optional) represents the full jndi name where to bind the destination.
- If this is not specified then the destination will be bound in <DefaultQueueJNDIContext>/<name>.
- </para>
+ <para>The <literal>jndiName</literal> parameter (optional)
+ represents the full jndi name where to bind the destination. If this
+ is not specified then the destination will be bound in
+ <DefaultQueueJNDIContext>/<name>.</para>
- <para>The first version of this operation deploys the destination with the default paging parameters. The second overloaded version deploys
- the destination with the specified paging parameters. See the section on configuring destinations for a discussion of what the
- paging parameters mean.</para>
+ <para>The first version of this operation deploys the destination
+ with the default paging parameters. The second overloaded version
+ deploys the destination with the specified paging parameters. See
+ the section on configuring destinations for a discussion of what the
+ paging parameters mean.</para>
+ </section>
- </section>
+ <section id="conf.serverpeer.operations.undeployQueue">
+ <title>UndeployQueue</title>
- <section id="conf.serverpeer.operations.undeployQueue">
- <title>UndeployQueue</title>
+ <para>This operation lets you programmatically undeploy a
+ queue.</para>
- <para>
- This operation lets you programmatically undeploy a queue.
- </para>
+ <para>The queue is undeployed but is NOT removed from persistent
+ storage.</para>
- <para>The queue is undeployed but is NOT removed from persistent storage.</para>
+ <para>This operation returns <literal>true</literal> if the queue
+ was successfull undeployed. otherwise it returns
+ <literal>false</literal>.</para>
+ </section>
- <para>This operation returns <literal>true</literal> if the queue was successfull undeployed. otherwise it returns <literal>false</literal>.</para>
+ <section id="conf.serverpeer.operations.destroyQueue">
+ <title>DestroyQueue</title>
- </section>
+ <para>This operation lets you programmatically destroy a
+ queue.</para>
- <section id="conf.serverpeer.operations.destroyQueue">
- <title>DestroyQueue</title>
+ <para>The queue is undeployed and then all its data is destroyed
+ from the database.</para>
- <para>
- This operation lets you programmatically destroy a queue.
- </para>
+ <warning>
+ Be careful when using this method since it will delete all data for the queue.
+ </warning>
- <para>The queue is undeployed and then all its data is destroyed from the database.</para>
+ <para>This operation returns <literal>true</literal> if the queue
+ was successfully destroyed. otherwise it returns
+ <literal>false</literal>.</para>
+ </section>
- <warning>Be careful when using this method since it will delete all data for the queue.</warning>
+ <section id="conf.serverpeer.operations.deployTopic">
+ <title>DeployTopic</title>
- <para>This operation returns <literal>true</literal> if the
- queue was successfully destroyed. otherwise it returns <literal>false</literal>.</para>
+ <para>This operation lets you programmatically deploy a
+ topic.</para>
- </section>
+ <para>There are two overloaded versions of this operation.</para>
- <section id="conf.serverpeer.operations.deployTopic">
-
- <title>DeployTopic</title>
+ <para>If the topic already exists but is undeployed it is deployed.
+ Otherwise it is created and deployed.</para>
- <para>
- This operation lets you programmatically deploy a topic.
- </para>
+ <para>The <literal>name</literal> parameter represents the name of
+ the destination to deploy.</para>
- <para>There are two overloaded versions of this operation.</para>
+ <para>The <literal>jndiName</literal> parameter (optional)
+ represents the full jndi name where to bind the destination. If this
+ is not specified then the destination will be bound in
+ <DefaultTopicJNDIContext>/<name>.</para>
- <para>If the topic already exists but is undeployed it is deployed. Otherwise it is created and deployed.</para>
+ <para>The first version of this operation deploys the destination
+ with the default paging parameters. The second overloaded version
+ deploys the destination with the specified paging parameters. See
+ the section on configuring destinations for a discussion of what the
+ paging parameters mean.</para>
+ </section>
- <para>The <literal>name</literal> parameter represents the name of the destination to deploy.</para>
- <para>The <literal>jndiName</literal> parameter (optional) represents the full jndi name where to bind the destination. If this is not specified
- then the destination will be bound in <DefaultTopicJNDIContext>/<name>.</para>
+ <section id="conf.serverpeer.operations.undeployTopic">
+ <title>UndeployTopic</title>
- <para>The first version of this operation deploys the destination with the default paging parameters. The second overloaded version deploys
- the destination with the specified paging parameters. See the section on configuring destinations for a discussion of what the
- paging parameters mean.</para>
+ <para>This operation lets you programmatically undeploy a
+ topic.</para>
- </section>
+ <para>The queue is undeployed but is NOT removed from persistent
+ storage.</para>
- <section id="conf.serverpeer.operations.undeployTopic">
- <title>UndeployTopic</title>
+ <para>This operation returns <literal>true</literal> if the topic
+ was successfully undeployed. otherwise it returns
+ <literal>false</literal>.</para>
+ </section>
- <para>
- This operation lets you programmatically undeploy a topic.
- </para>
+ <section id="conf.serverpeer.operations.destroyTopic">
+ <title>DestroyTopic</title>
- <para>The queue is undeployed but is NOT removed from persistent storage.</para>
+ <para>This operation lets you programmatically destroy a
+ topic.</para>
- <para>This operation returns <literal>true</literal> if the topic was successfully undeployed. otherwise it returns <literal>false</literal>.</para>
+ <para>The topic is undeployed and then all its data is destroyed
+ from the database.</para>
- </section>
+ <warning>
+ Be careful when using this method since it will delete all data for the topic.
+ </warning>
- <section id="conf.serverpeer.operations.destroyTopic">
- <title>DestroyTopic</title>
+ <para>This operation returns <literal>true</literal> if the topic
+ was successfully destroyed. otherwise it returns
+ <literal>false</literal>.</para>
+ </section>
- <para>
- This operation lets you programmatically destroy a topic.
- </para>
+ <section id="conf.serverpeer.operations.listmessagecountersashtml">
+ <title>ListMessageCountersHTML</title>
- <para>The topic is undeployed and then all its data is destroyed from the database.</para>
+ <para>This operation returns message counters in an easy to display
+ HTML format.</para>
+ </section>
- <warning>Be careful when using this method since it will delete all data for the topic.</warning>
+ <section id="conf.serverpeer.operations.resetallmessagecounters">
+ <title>ResetAllMesageCounters</title>
- <para>This operation returns <literal>true</literal> if the topic was successfully destroyed. otherwise it returns <literal>false</literal>.</para>
+ <para>This operation resets all message counters to zero.</para>
+ </section>
- </section>
+ <section id="conf.serverpeer.operations.resetallmessagecounterhistories">
+ <title>ResetAllMesageCounters</title>
- <section id="conf.serverpeer.operations.listmessagecountersashtml">
- <title>ListMessageCountersHTML</title>
+ <para>This operation resets all message counter histories to
+ zero.</para>
+ </section>
- <para>
- This operation returns message counters in an easy to display HTML format.
- </para>
- </section>
+ <section id="conf.serverpeer.operations.enablemessagecounters">
+ <title>EnableMessageCounters</title>
- <section id="conf.serverpeer.operations.resetallmessagecounters">
- <title>ResetAllMesageCounters</title>
+ <para>This operation enables all message counters for all
+ destinations. Message counters are disabled by default.</para>
+ </section>
- <para>
- This operation resets all message counters to zero.
- </para>
- </section>
+ <section id="conf.serverpeer.operations.disablemessagecounters">
+ <title>DisableMessageCounters</title>
+ <para>This operation disables all message counters for all
+ destinations. Message counters are disabled by default.</para>
+ </section>
- <section id="conf.serverpeer.operations.resetallmessagecounterhistories">
- <title>ResetAllMesageCounters</title>
+ <section id="conf.serverpeer.operations.retrievepreparedtransactions">
+ <title>RetrievePreparedTransactions</title>
- <para>
- This operation resets all message counter histories to zero.
- </para>
- </section>
+ <para>Retrieves a list of the Xids for all transactions currently in
+ a prepared state on the node.</para>
+ </section>
- <section id="conf.serverpeer.operations.enablemessagecounters">
- <title>EnableMessageCounters</title>
+ <section id="conf.serverpeer.operations.showpreparedtransactions">
+ <title>ShowPreparedTransactions</title>
- <para>
- This operation enables all message counters for all destinations. Message counters are disabled by default.
- </para>
- </section>
-
- <section id="conf.serverpeer.operations.disablemessagecounters">
- <title>DisableMessageCounters</title>
-
- <para>
- This operation disables all message counters for all destinations. Message counters are disabled by default.
- </para>
- </section>
-
- <section id="conf.serverpeer.operations.retrievepreparedtransactions">
- <title>RetrievePreparedTransactions</title>
-
- <para>
- Retrieves a list of the Xids for all transactions currently in a prepared state on the node.
- </para>
- </section>
-
- <section id="conf.serverpeer.operations.showpreparedtransactions">
- <title>ShowPreparedTransactions</title>
-
- <para>
- Retrieves a list of the Xids for all transactions currently in a prepared state on the node in an easy to display HTML format.
- </para>
- </section>
-
+ <para>Retrieves a list of the Xids for all transactions currently in
+ a prepared state on the node in an easy to display HTML
+ format.</para>
+ </section>
</section>
+ </section>
+ </section>
- </section>
-
- </section>
+ <section id="conf.changingds">
+ <title>Changing the Database</title>
- <section id="conf.changingds">
- <title>Changing the Database</title>
+ <para>Several JBoss Messaging services interact with persistent storage.
+ They include: The Persistence Manager, The PostOffice and the JMS User
+ Manager. The Persistence Manager is used to handle the message-related
+ persistence. The Post Office handles binding related persistence. The JMS
+ User manager handles user related persistence The configuration for all
+ these MBeans is handled in the
+ <filename>xxx-persistence-service.xml</filename> file.</para>
- <para>
- Several JBoss Messaging services interact with persistent storage. They include: The Persistence Manager,
- The PostOffice and the JMS User Manager.
- The Persistence Manager is used to handle the message-related persistence.
- The Post Office handles binding related persistence.
- The JMS User manager handles user related persistence
- The configuration for all these MBeans is handled in the <filename>xxx-persistence-service.xml</filename> file.
- </para>
+ <para>If the database you want to switch to is one of MySQL, Oracle,
+ PostgreSQL, MS SQL Sever or Sybase, persistence configuration files are
+ already available in the <filename>examples/config</filename> directory of
+ the release bundle.</para>
- <para>
- If the database you want to switch to is one of MySQL, Oracle, PostgreSQL, MS SQL Sever or Sybase,
- persistence configuration files are already available in
- the <filename>examples/config</filename> directory of the release bundle.
- </para>
+ <para>In order to enable support for one of these databases, just replace
+ the default <filename>hsqldb-persistence-service.xml</filename>
+ configuration file with the database-specific configuration file and
+ restart the server.</para>
- <para>
- In order to enable support for one of these databases, just replace the default
- <filename>hsqldb-persistence-service.xml</filename> configuration file with the
- database-specific configuration file and restart the server.
- </para>
+ <para>Also, be aware that by default, the Messaging services relying on a
+ datastore are referencing <literal>"java:/DefaultDS"</literal> for the
+ datasource. If you are deploying a datasource with a different JNDI name,
+ you need to update all the <literal>DataSource</literal> attribute in the
+ persistence configuration file. Example data source configurations for
+ each of the popular databases are available in the distribution.</para>
+ </section>
- <para>
- Also, be aware that by default, the Messaging services relying on a datastore
- are referencing <literal>"java:/DefaultDS"</literal> for the datasource.
- If you are deploying a datasource with a different JNDI name, you need to update
- all the <literal>DataSource</literal> attribute in the persistence configuration file.
+ <section id="conf.postoffice">
+ <title>Configuring the Post office</title>
- Example data source configurations for each of the popular databases are available in the distribution.
- </para>
+ <para>It is the job of the post office to route messages to their
+ destination(s).</para>
- </section>
+ <para>The post office maintains the mappings between addresses to which
+ messages can be sent and their final queues.</para>
+ <para>For example when sending a message with an address that represents a
+ JMS queue name, the post office will route this to a single queue - the
+ JMS queue. When sending a message with an address that repesents a JMS
+ topic name, the post office will route this to a set of queues - one for
+ each JMS subscription.</para>
- <section id="conf.postoffice">
- <title>Configuring the Post office</title>
+ <para>The post office also handles the persistence for the mapping of
+ addresses.</para>
- <para>It is the job of the post office to route messages to their destination(s).
- </para>
+ <para>JBoss messaging are also cluster aware. In a cluster they will
+ automatically route and pull messages between them in order to provide
+ fully distributed JMS queues and topics.</para>
- <para>The post office maintains the mappings between addresses to which messages can be sent and their final queues.</para>
+ <para>The post office configuration is found in the
+ xxx-persistence-service.xml file (where xxx is the name of your
+ database).</para>
- <para>For example when sending a message with an address that represents a JMS queue name, the post office will route this to a single
- queue - the JMS queue. When sending a message with an address that repesents a JMS topic name, the post office will route this to a set of
- queues - one for each JMS subscription.</para>
+ <para>Here is an example of a post office configuration:</para>
- <para>The post office also handles the persistence for the mapping of addresses.</para>
-
- <para>JBoss messaging are also cluster aware. In a cluster they will automatically route and pull messages between them in order to provide fully distributed JMS queues and topics.</para>
-
- <para>The post office configuration is found in the xxx-persistence-service.xml file (where xxx is the name of your database).
- </para>
-
- <para>Here is an example of a post office configuration:</para>
-
- <programlisting>
+ <programlisting>
<mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService"
name="jboss.messaging:service=PostOffice"
xmbean-dd="xmdesc/MessagingPostOffice-xmbean.xml">
@@ -887,182 +856,182 @@
</attribute>
</mbean>
</programlisting>
-
- <section id="conf.postoffice.attributes">
- <title>The post office has the following attributes</title>
+ <section id="conf.postoffice.attributes">
+ <title>The post office has the following attributes</title>
- <section id="conf.postoffice.attributes.datasource">
- <title>DataSource</title>
- <para>The datasource the postoffice should use for persisting its mapping data.</para>
- </section>
+ <section id="conf.postoffice.attributes.datasource">
+ <title>DataSource</title>
- <section id="conf.postoffice.attributes.sqlproperties">
- <title>SQLProperties</title>
- <para>
- This is where the DDL and DML for the particular database is specified.
- If a particular DDL or DML statement is not overridden, the default Hypersonic
- configuration will be used for that statement.
- </para>
- </section>
+ <para>The datasource the postoffice should use for persisting its
+ mapping data.</para>
+ </section>
- <section id="conf.postoffice.attributes.createtables">
- <title>CreateTablesOnStartup</title>
+ <section id="conf.postoffice.attributes.sqlproperties">
+ <title>SQLProperties</title>
- <para>
- Set this to <literal>true</literal> if you wish the post office to attempt
- to create the tables (and indexes) when it starts. If the tables (or indexes)
- already exist a <literal>SQLException</literal> will be thrown by the JDBC driver and
- ignored by the Persistence Manager, allowing it to continue.
- </para>
- <para>
- By default the value of <literal>CreateTablesOnStartup</literal> attribute
- is set to <literal>true</literal>
- </para>
- </section>
+ <para>This is where the DDL and DML for the particular database is
+ specified. If a particular DDL or DML statement is not overridden, the
+ default Hypersonic configuration will be used for that
+ statement.</para>
+ </section>
- <section id="conf.postoffice.attributes.postofficename">
- <title>PostOfficeName</title>
+ <section id="conf.postoffice.attributes.createtables">
+ <title>CreateTablesOnStartup</title>
- <para>
- The name of the post office.
- </para>
- </section>
+ <para>Set this to <literal>true</literal> if you wish the post office
+ to attempt to create the tables (and indexes) when it starts. If the
+ tables (or indexes) already exist a <literal>SQLException</literal>
+ will be thrown by the JDBC driver and ignored by the Persistence
+ Manager, allowing it to continue.</para>
- <section id="conf.postoffice.attributes.nodeidview">
- <title>NodeIDView</title>
+ <para>By default the value of <literal>CreateTablesOnStartup</literal>
+ attribute is set to <literal>true</literal></para>
+ </section>
- <para>
- This returns set containing the node ids of all the nodes in the cluster.
- </para>
- </section>
+ <section id="conf.postoffice.attributes.postofficename">
+ <title>PostOfficeName</title>
- <section id="conf.postoffice.attributes.groupname">
- <title>GroupName</title>
+ <para>The name of the post office.</para>
+ </section>
- <para>
- All post offices in the cluster with the same group name will form a cluster together. Make sure the group name matches with
- all the nodes in the cluster you want to form a cluster with.
- </para>
- </section>
+ <section id="conf.postoffice.attributes.nodeidview">
+ <title>NodeIDView</title>
- <section id="conf.postoffice.attributes.clustered">
- <title>Clustered</title>
+ <para>This returns set containing the node ids of all the nodes in the
+ cluster.</para>
+ </section>
- <para>
- If true the post office will take part in a cluster to form distributed queues and topics. If false then it will not participate in the cluster. If false, then all the cluster related attributes will be ignored.
- </para>
- </section>
+ <section id="conf.postoffice.attributes.groupname">
+ <title>GroupName</title>
- <section id="conf.postoffice.attributes.statetimeout">
- <title>StateTimeout</title>
- <para>The maximum time to wait when waiting for the group state to arrive when a node joins a pre-existing cluster.
- </para>
- <para>The default value is <literal>5000</literal> milliseconds.
- </para>
- </section>
+ <para>All post offices in the cluster with the same group name will
+ form a cluster together. Make sure the group name matches with all the
+ nodes in the cluster you want to form a cluster with.</para>
+ </section>
- <section id="conf.postoffice.attributes.casttimeout">
- <title>CastTimeout</title>
- <para>
- The maximum time to wait for a reply casting message synchronously.
- </para>
- <para>The default value is <literal>5000</literal> milliseconds.
- </para>
- </section>
+ <section id="conf.postoffice.attributes.clustered">
+ <title>Clustered</title>
- <section id="conf.postoffice.attributes.controlchannelconfig">
- <title>ControlChannelConfig</title>
- <para>JBoss Messaging uses JGroups for all group management. This contains the JGroups stack configuration for the control channel.
- </para>
- <para>The control channel is used for sending request/receiving responses from other nodes in the cluster</para>
- <para>
- The details of the JGroups configuration won't be discussed here since it is standard JGroups configuration.
- Detailed information on JGroups can be found in JGroups release documentation or on-line at
- <ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink> or
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups</ulink>.
- </para>
- </section>
+ <para>If true the post office will take part in a cluster to form
+ distributed queues and topics. If false then it will not participate
+ in the cluster. If false, then all the cluster related attributes will
+ be ignored.</para>
+ </section>
- <section id="conf.postoffice.attributes.asyncchannelconfig">
- <title>DataChannelConfig</title>
- <para>
- JBoss Messaging uses JGroups for all group management. This contains the JGroups stack configuration for the data channel.
- </para>
- <para>The data channel is used for sending sending/receiving messages from other nodes in the cluster.</para>
- <para>
- The details of the JGroups configuration won't be discussed here since it is standard JGroups configuration.
- Detailed information on JGroups can be found in JGroups release documentation or on-line at
- <ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink> or
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups</ulink>.
- </para>
- </section>
-
- </section>
-
- </section>
-
-
- <section id="conf.persistencemanager">
- <title>Configuring the Persistence Manager</title>
-
- <para>It is the job of the persistence manager to manage all message related persistence.
- </para>
-
- <para>
- JBoss Messaging ships with a JDBC Persistence Manager used for handling persistence of
- message data in a relational database accessed via JDBC. The Persistence Manager
- implementation is pluggable (the Persistence Manager is a Messaging server plug-in),
- this making possible to provide other implementations for persisting message data in
- non relational stores, file stores etc.
- </para>
-
- <para>
- The configuration of "persistent" services is grouped in a
- <filename>xxx-persistence-service.xml</filename> file, where the actual file prefix is
- usually inferred from its corresponding database JDBC connection string. By default,
- Messaging ships with a <filename>hsqldb-persistence-service.xml</filename>, which configures
- the Messaging server to use the in-VM Hypersonic database instance that comes by default
- with any JBossAS instance.
- </para>
-
- <warning>
- <para>
- The default Persistence Manager configuration is works out of the box with Hypersonic,
- however it must be stressed that Hypersonic should not be used in a production environment
- mainly due to its limited support for transaction isolation and its propensity to behave
- erratically under high load.
- </para>
- <para>
- The
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB">Critique of Hypersonic</ulink>
- wiki page outlines some of the well-known issues occuring when using this database.
- </para>
- </warning>
-
- <para>
- JBoss Messaging also ships with pre-made Persistence Manager configurations for MySQL,
- Oracle, PostgreSQL, Sybase and MS SQL Server. The example <filename>mysql-persistence-service.xml</filename>,
- <filename>oracle-persistence-service.xml</filename>,
- <filename>postgres-persistence-service.xml</filename> and
- <filename>sybase-persistence-service.xml</filename> and
- <filename>mssql-persistence-service.xml</filename> configuration files are available
- in the <filename>examples/config</filename> directory of the release bundle.
- </para>
-
- <para>
- Users are encouraged to contribute their own configuration files where we will thoroughly test them before certifying them for suppported use
- with JBoss Messaging. The JDBC Persistence Manager has been designed
- to use standard SQL for the DML so writing a JDBC Persistence Manager configuration for another
- database is usually only a fairly simple matter of changing DDL in the configuration
- which is likely to be different for different databases.
- </para>
-
- <para>
- The default Hypersonic persistence configuration file is listed below:
- </para>
-
- <programlisting>
+ <section id="conf.postoffice.attributes.statetimeout">
+ <title>StateTimeout</title>
+
+ <para>The maximum time to wait when waiting for the group state to
+ arrive when a node joins a pre-existing cluster.</para>
+
+ <para>The default value is <literal>5000</literal>
+ milliseconds.</para>
+ </section>
+
+ <section id="conf.postoffice.attributes.casttimeout">
+ <title>CastTimeout</title>
+
+ <para>The maximum time to wait for a reply casting message
+ synchronously.</para>
+
+ <para>The default value is <literal>5000</literal>
+ milliseconds.</para>
+ </section>
+
+ <section id="conf.postoffice.attributes.controlchannelconfig">
+ <title>ControlChannelConfig</title>
+
+ <para>JBoss Messaging uses JGroups for all group management. This
+ contains the JGroups stack configuration for the control
+ channel.</para>
+
+ <para>The control channel is used for sending request/receiving
+ responses from other nodes in the cluster</para>
+
+ <para>The details of the JGroups configuration won't be discussed here
+ since it is standard JGroups configuration. Detailed information on
+ JGroups can be found in JGroups release documentation or on-line at
+ <ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink> or
+ <ulink
+ url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups</ulink>.</para>
+ </section>
+
+ <section id="conf.postoffice.attributes.asyncchannelconfig">
+ <title>DataChannelConfig</title>
+
+ <para>JBoss Messaging uses JGroups for all group management. This
+ contains the JGroups stack configuration for the data channel.</para>
+
+ <para>The data channel is used for sending sending/receiving messages
+ from other nodes in the cluster.</para>
+
+ <para>The details of the JGroups configuration won't be discussed here
+ since it is standard JGroups configuration. Detailed information on
+ JGroups can be found in JGroups release documentation or on-line at
+ <ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink> or
+ <ulink
+ url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups</ulink>.</para>
+ </section>
+ </section>
+ </section>
+
+ <section id="conf.persistencemanager">
+ <title>Configuring the Persistence Manager</title>
+
+ <para>It is the job of the persistence manager to manage all message
+ related persistence.</para>
+
+ <para>JBoss Messaging ships with a JDBC Persistence Manager used for
+ handling persistence of message data in a relational database accessed via
+ JDBC. The Persistence Manager implementation is pluggable (the Persistence
+ Manager is a Messaging server plug-in), this making possible to provide
+ other implementations for persisting message data in non relational
+ stores, file stores etc.</para>
+
+ <para>The configuration of "persistent" services is grouped in a
+ <filename>xxx-persistence-service.xml</filename> file, where the actual
+ file prefix is usually inferred from its corresponding database JDBC
+ connection string. By default, Messaging ships with a
+ <filename>hsqldb-persistence-service.xml</filename>, which configures the
+ Messaging server to use the in-VM Hypersonic database instance that comes
+ by default with any JBossAS instance.</para>
+
+ <warning>
+ <para>The default Persistence Manager configuration is works out of the
+ box with Hypersonic, however it must be stressed that Hypersonic should
+ not be used in a production environment mainly due to its limited
+ support for transaction isolation and its propensity to behave
+ erratically under high load.</para>
+
+ <para>The <ulink
+ url="http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB">Critique
+ of Hypersonic</ulink> wiki page outlines some of the well-known issues
+ occuring when using this database.</para>
+ </warning>
+
+ <para>JBoss Messaging also ships with pre-made Persistence Manager
+ configurations for MySQL, Oracle, PostgreSQL, Sybase and MS SQL Server.
+ The example <filename>mysql-persistence-service.xml</filename>,
+ <filename>oracle-persistence-service.xml</filename>,
+ <filename>postgres-persistence-service.xml</filename> and
+ <filename>sybase-persistence-service.xml</filename> and
+ <filename>mssql-persistence-service.xml</filename> configuration files are
+ available in the <filename>examples/config</filename> directory of the
+ release bundle.</para>
+
+ <para>Users are encouraged to contribute their own configuration files
+ where we will thoroughly test them before certifying them for suppported
+ use with JBoss Messaging. The JDBC Persistence Manager has been designed
+ to use standard SQL for the DML so writing a JDBC Persistence Manager
+ configuration for another database is usually only a fairly simple matter
+ of changing DDL in the configuration which is likely to be different for
+ different databases.</para>
+
+ <para>The default Hypersonic persistence configuration file is listed
+ below:</para>
+
+ <programlisting>
<mbean code="org.jboss.messaging.core.jmx.JDBCPersistenceManagerService"
name="jboss.messaging:service=PersistenceManager"
@@ -1168,106 +1137,97 @@
</mbean>
</programlisting>
- <section id="conf.persistencemanager.attributes">
+ <section id="conf.persistencemanager.attributes">
+ <title>We now discuss the MBean attributes of the PersistenceManager
+ MBean</title>
+ <section id="conf.persistencemanager.attributes.createtables">
+ <title>CreateTablesOnStartup</title>
- <title>
- We now discuss the MBean attributes of the PersistenceManager MBean
- </title>
+ <para>Set this to <literal>true</literal> if you wish the Persistence
+ Manager to attempt to create the tables (and indexes) when it starts.
+ If the tables (or indexes) already exist a
+ <literal>SQLException</literal> will be thrown by the JDBC driver and
+ ignored by the Persistence Manager, allowing it to continue.</para>
- <section id="conf.persistencemanager.attributes.createtables">
- <title>CreateTablesOnStartup</title>
-
- <para>
- Set this to <literal>true</literal> if you wish the Persistence Manager to attempt
- to create the tables (and indexes) when it starts. If the tables (or indexes)
- already exist a <literal>SQLException</literal> will be thrown by the JDBC driver and
- ignored by the Persistence Manager, allowing it to continue.
- </para>
- <para>
- By default the value of <literal>CreateTablesOnStartup</literal> attribute
- is set to <literal>true</literal>
- </para>
- </section>
+ <para>By default the value of <literal>CreateTablesOnStartup</literal>
+ attribute is set to <literal>true</literal></para>
+ </section>
- <section id="conf.persistencemanager.attributes.batchupdates">
- <title>UsingBatchUpdates</title>
-
- <para>
- Set this to <literal>true</literal> if the database supports JDBC batch updates.
- The JDBC Persistence Manager will then group multiple database updates in batches
- to aid performance.
- </para>
- <para>
- By default the value of <literal>UsingBatchUpdates</literal> attribute
- is set to <literal>false</literal>
- </para>
- </section>
+ <section id="conf.persistencemanager.attributes.batchupdates">
+ <title>UsingBatchUpdates</title>
- <section id="conf.persistencemanager.attributes.binarystream">
- <title>UsingBinaryStream</title>
-
- <para>
- Set this to <literal>true</literal> if you want messages to be store and read using a JDBC binary stream rather than using
- getBytes(), setBytes(). Some database has limits on the maximum number of bytes that can be get/set using getBytes()/setBytes().
- </para>
- <para>
- By default the value of <literal>UsingBinaryStream</literal> attribute
- is set to <literal>true</literal>
- </para>
- </section>
+ <para>Set this to <literal>true</literal> if the database supports
+ JDBC batch updates. The JDBC Persistence Manager will then group
+ multiple database updates in batches to aid performance.</para>
- <section id="conf.persistencemanager.attributes.trailingbyte">
- <title>UsingTrailingByte</title>
-
- <para>
- Certain version of Sybase are known to truncate blobs if they have trailing zeros. To prevent this if this attribute is set to
- <literal>true</literal> then a trailing non zero byte will be added and removed to each blob before and after persistence to prevent
- the database from truncating it. Currently this is only known to be necessary for Sybase.
- </para>
- <para>
- By default the value of <literal>UsingTrailingByte</literal> attribute
- is set to <literal>false</literal>
- </para>
- </section>
+ <para>By default the value of <literal>UsingBatchUpdates</literal>
+ attribute is set to <literal>false</literal></para>
+ </section>
- <section id="conf.persistencemanager.attributes.sqlproperties">
- <title>SQLProperties</title>
-
- <para>
- This is where the DDL and DML for the particular database is specified.
- If a particular DDL or DML statement is not overridden, the default Hypersonic
- configuration will be used for that statement.
- </para>
- </section>
+ <section id="conf.persistencemanager.attributes.binarystream">
+ <title>UsingBinaryStream</title>
- <section id="conf.persistencemanager.attributes.maxparams">
- <title>MaxParams</title>
-
- <para>
- When loading messages the persistence manager will generate prepared statements with many parameters. This value tells the persistence
- manager what the absolute maximum number of parameters are allowable per prepared statement.
-
- </para>
- <para>
- By default the value of <literal>MaxParams</literal> attribute
- is set to <literal>100</literal>
- </para>
- </section>
+ <para>Set this to <literal>true</literal> if you want messages to be
+ store and read using a JDBC binary stream rather than using
+ getBytes(), setBytes(). Some database has limits on the maximum number
+ of bytes that can be get/set using getBytes()/setBytes().</para>
- </section> <!-- end conf.persistencemanager.attributes -->
-
- </section> <!-- end conf.persistencemanager -->
+ <para>By default the value of <literal>UsingBinaryStream</literal>
+ attribute is set to <literal>true</literal></para>
+ </section>
- <section id="conf.jmsusermanager">
- <title>Configuring the JMS user manager</title>
+ <section id="conf.persistencemanager.attributes.trailingbyte">
+ <title>UsingTrailingByte</title>
- <para>The JMS user manager handles the mapping of pre-configured client IDs to users and also managers the user and role tables which may or
- may not be used depending on which login module you have configured</para>
-
- <para>Here is an example JMSUserManager configuration</para>
+ <para>Certain version of Sybase are known to truncate blobs if they
+ have trailing zeros. To prevent this if this attribute is set to
+ <literal>true</literal> then a trailing non zero byte will be added
+ and removed to each blob before and after persistence to prevent the
+ database from truncating it. Currently this is only known to be
+ necessary for Sybase.</para>
- <programlisting wrap-option="true">
+ <para>By default the value of <literal>UsingTrailingByte</literal>
+ attribute is set to <literal>false</literal></para>
+ </section>
+
+ <section id="conf.persistencemanager.attributes.sqlproperties">
+ <title>SQLProperties</title>
+
+ <para>This is where the DDL and DML for the particular database is
+ specified. If a particular DDL or DML statement is not overridden, the
+ default Hypersonic configuration will be used for that
+ statement.</para>
+ </section>
+
+ <section id="conf.persistencemanager.attributes.maxparams">
+ <title>MaxParams</title>
+
+ <para>When loading messages the persistence manager will generate
+ prepared statements with many parameters. This value tells the
+ persistence manager what the absolute maximum number of parameters are
+ allowable per prepared statement.</para>
+
+ <para>By default the value of <literal>MaxParams</literal> attribute
+ is set to <literal>100</literal></para>
+ </section>
+ </section>
+
+ <!-- end conf.persistencemanager.attributes -->
+ </section>
+
+ <!-- end conf.persistencemanager -->
+
+ <section id="conf.jmsusermanager">
+ <title>Configuring the JMS user manager</title>
+
+ <para>The JMS user manager handles the mapping of pre-configured client
+ IDs to users and also managers the user and role tables which may or may
+ not be used depending on which login module you have configured</para>
+
+ <para>Here is an example JMSUserManager configuration</para>
+
+ <programlisting wrap-option="true">
<mbean code="org.jboss.jms.server.plugin.JDBCJMSUserManagerService"
name="jboss.messaging:service=JMSUserManager"
xmbean-dd="xmdesc/JMSUserManager-xmbean.xml">
@@ -1291,78 +1251,66 @@
</mbean>
</programlisting>
- <section id="conf.jmsusermanager.attributes">
+ <section id="conf.jmsusermanager.attributes">
+ <title>We now discuss the MBean attributes of the JMSUserManager
+ MBean</title>
+ <section id="conf.jmsusermanager.attributes.createtables">
+ <title>CreateTablesOnStartup</title>
- <title>
- We now discuss the MBean attributes of the JMSUserManager MBean
- </title>
+ <para>Set this to <literal>true</literal> if you wish the JMS user
+ manager to attempt to create the tables (and indexes) when it starts.
+ If the tables (or indexes) already exist a
+ <literal>SQLException</literal> will be thrown by the JDBC driver and
+ ignored by the Persistence Manager, allowing it to continue.</para>
- <section id="conf.jmsusermanager.attributes.createtables">
- <title>CreateTablesOnStartup</title>
-
- <para>
- Set this to <literal>true</literal> if you wish the JMS user manager to attempt
- to create the tables (and indexes) when it starts. If the tables (or indexes)
- already exist a <literal>SQLException</literal> will be thrown by the JDBC driver and
- ignored by the Persistence Manager, allowing it to continue.
- </para>
- <para>
- By default the value of <literal>CreateTablesOnStartup</literal> attribute
- is set to <literal>true</literal>
- </para>
- </section>
+ <para>By default the value of <literal>CreateTablesOnStartup</literal>
+ attribute is set to <literal>true</literal></para>
+ </section>
- <section id="conf.jmsusermanager.attributes.batchupdates">
- <title>UsingBatchUpdates</title>
-
- <para>
- Set this to <literal>true</literal> if the database supports JDBC batch updates.
- The JDBC Persistence Manager will then group multiple database updates in batches
- to aid performance.
- </para>
- <para>
- By default the value of <literal>UsingBatchUpdates</literal> attribute
- is set to <literal>false</literal>
- </para>
- </section>
+ <section id="conf.jmsusermanager.attributes.batchupdates">
+ <title>UsingBatchUpdates</title>
+ <para>Set this to <literal>true</literal> if the database supports
+ JDBC batch updates. The JDBC Persistence Manager will then group
+ multiple database updates in batches to aid performance.</para>
- <section id="conf.jmsusermanager.attributes.sqlproperties">
- <title>SQLProperties</title>
-
- <para>
- This is where the DDL and DML for the particular database is specified.
- If a particular DDL or DML statement is not overridden, the default Hypersonic
- configuration will be used for that statement.
- </para>
-
- <para>
- Default user and role data can also be specified here. Any data to be inserted must be specified with property names starting with
- <literal>POPULATE.TABLES</literal> as in the above example.
- </para>
- </section>
+ <para>By default the value of <literal>UsingBatchUpdates</literal>
+ attribute is set to <literal>false</literal></para>
+ </section>
+ <section id="conf.jmsusermanager.attributes.sqlproperties">
+ <title>SQLProperties</title>
- </section> <!-- end conf.jmsusermanager.attributes -->
+ <para>This is where the DDL and DML for the particular database is
+ specified. If a particular DDL or DML statement is not overridden, the
+ default Hypersonic configuration will be used for that
+ statement.</para>
- </section> <!-- end.conf.jmsusermanager -->
+ <para>Default user and role data can also be specified here. Any data
+ to be inserted must be specified with property names starting with
+ <literal>POPULATE.TABLES</literal> as in the above example.</para>
+ </section>
+ </section>
+ <!-- end conf.jmsusermanager.attributes -->
+ </section>
- <section id="conf.destination">
- <title>Configuring Destinations</title>
+ <!-- end.conf.jmsusermanager -->
- <section id="conf.preconf.destinations">
- <title>Pre-configured destinations</title>
+ <section id="conf.destination">
+ <title>Configuring Destinations</title>
- <para>
- JBoss Messaging ships with a default set of pre-configured destinations that will be
- deployed during the server start up. The file that contains configuration for these
- destinations is <filename>destinations-service.xml</filename>. A section of
- this file is listed below:
- </para>
+ <section id="conf.preconf.destinations">
+ <title>Pre-configured destinations</title>
- <programlisting>
+ <para>JBoss Messaging ships with a default set of pre-configured
+ destinations that will be deployed during the server start up. The file
+ that contains configuration for these destinations is
+ <filename>destinations-service.xml</filename>. A section of this file is
+ listed below:</para>
+
+ <programlisting>
<!--
The Default Dead Letter Queue. This destination is a dependency of an EJB MDB container.
-->
@@ -1508,189 +1456,176 @@
</mbean>
....
</programlisting>
+ </section>
- </section> <!-- end conf.preconf.destinations -->
+ <!-- end conf.preconf.destinations -->
+ <section id="conf.destination.queue">
+ <title>Configuring queues</title>
- <section id="conf.destination.queue">
+ <section id="conf.destination.queue.attributes">
+ <title>We now discuss the attributes of the Queue MBean</title>
- <title>Configuring queues</title>
+ <section id="conf.destination.queue.attributes.name">
+ <title>Name</title>
- <section id="conf.destination.queue.attributes">
+ <para>The name of the queue</para>
+ </section>
- <title>
- We now discuss the attributes of the Queue MBean
- </title>
+ <section id="conf.destination.queue.attributes.jndiName">
+ <title>JNDIName</title>
- <section id="conf.destination.queue.attributes.name">
- <title>Name</title>
- <para>The name of the queue</para>
- </section>
+ <para>The JNDI name where the queue is bound</para>
+ </section>
- <section id="conf.destination.queue.attributes.jndiName">
- <title>JNDIName</title>
- <para>The JNDI name where the queue is bound</para>
- </section>
+ <section id="conf.destination.queue.attributes.dlq">
+ <title>DLQ</title>
- <section id="conf.destination.queue.attributes.dlq">
- <title>DLQ</title>
- <para>The DLQ used for this queue. Overrides any value set on the ServerPeer config</para>
- </section>
+ <para>The DLQ used for this queue. Overrides any value set on the
+ ServerPeer config</para>
+ </section>
- <section id="conf.destination.queue.attributes.expiryqueue">
- <title>ExpiryQueue</title>
- <para>The Expiry queue used for this queue. Overrides any value set on the ServerPeer config</para>
- </section>
+ <section id="conf.destination.queue.attributes.expiryqueue">
+ <title>ExpiryQueue</title>
- <section id="conf.destination.queue.attributes.redeliverydelay">
- <title>RedeliveryDelay</title>
- <para>The redelivery delay to be used for this queue. Overrides any value set on the ServerPeer config</para>
- </section>
-
- <section id="conf.destination.queue.attributes.maxdeliveryattempts">
- <title>MaxDeliveryAttempts</title>
- <para>
- The maximum number of times delivery of a message will be attempted before sending the message to the DLQ,
- if configured. If set to -1 (the default), the value from the ServerPeer config is used. Any other setting
- overrides the value set on the ServerPeer config.
- </para>
- </section>
+ <para>The Expiry queue used for this queue. Overrides any value set
+ on the ServerPeer config</para>
+ </section>
- <section id="conf.destination.queue.attributes.security">
- <title>Destination Security Configuration</title>
+ <section id="conf.destination.queue.attributes.redeliverydelay">
+ <title>RedeliveryDelay</title>
- <para>
- <literal>SecurityConfig</literal> - allows you to determine which roles are allowed
- to read, write and create on the destination. It has exactly the same syntax and
- semantics as the security configuration in JBossMQ destinations.
- </para>
+ <para>The redelivery delay to be used for this queue. Overrides any
+ value set on the ServerPeer config</para>
+ </section>
- <para>
- The <literal>SecurityConfig</literal> element should contain one
- <literal><security></literal> element. The <literal><security></literal>
- element can contain multiple <literal><role></literal> elements.
- Each <literal><role></literal> element defines the access for that
- particular role.
- </para>
+ <section id="conf.destination.queue.attributes.maxdeliveryattempts">
+ <title>MaxDeliveryAttempts</title>
- <para>
- If the <literal>read</literal> attribute is <literal>true</literal> then that role
- will be able to read (create consumers, receive messaages or browse) this destination.
- </para>
+ <para>The maximum number of times delivery of a message will be
+ attempted before sending the message to the DLQ, if configured. If
+ set to -1 (the default), the value from the ServerPeer config is
+ used. Any other setting overrides the value set on the ServerPeer
+ config.</para>
+ </section>
- <para>
- If the <literal>write</literal> attribute is <literal>true</literal> then that role
- will be able to write (create producers or send messages) to this destination.
- </para>
+ <section id="conf.destination.queue.attributes.security">
+ <title>Destination Security Configuration</title>
- <para>
- If the <literal>create</literal> attribute is <literal>true</literal> then that role
- will be able to create durable subscriptions on this destination.
- </para>
+ <para><literal>SecurityConfig</literal> - allows you to determine
+ which roles are allowed to read, write and create on the
+ destination. It has exactly the same syntax and semantics as the
+ security configuration in JBossMQ destinations.</para>
- <para>
- Note that the security configuration for a destination is optional. If a
- <literal>SecurityConfig</literal> element is not specifed then the default
- security configuration from the Server Peer will be used.
- </para>
- </section>
+ <para>The <literal>SecurityConfig</literal> element should contain
+ one <literal><security></literal> element. The
+ <literal><security></literal> element can contain multiple
+ <literal><role></literal> elements. Each
+ <literal><role></literal> element defines the access for that
+ particular role.</para>
- <section id="conf.destination.queue.attributes.paging">
- <title>Destination paging parameters</title>
+ <para>If the <literal>read</literal> attribute is
+ <literal>true</literal> then that role will be able to read (create
+ consumers, receive messaages or browse) this destination.</para>
- <para>
- 'Pageable Channels' are a sophisticated new feature available in JBoss Messaging.
- </para>
-
- <para>
- If your application needs to support very large queues or subscriptions containing
- potentially millions of messages, then it's not possible to store them all in
- memory at once.
- </para>
+ <para>If the <literal>write</literal> attribute is
+ <literal>true</literal> then that role will be able to write (create
+ producers or send messages) to this destination.</para>
- <para>
- JBoss Messaging solves this problem but letting you specify the
- maximum number of messages that can be stored in memory at any one time,
- on a queue-by-queue, or topic-by-topic basis. JBoss Messaging then pages messages
- to and from storage transparently in blocks, allowing queues and subscriptions to
- grow to very large sizes without any performance degradation as channel size increases.
- </para>
+ <para>If the <literal>create</literal> attribute is
+ <literal>true</literal> then that role will be able to create
+ durable subscriptions on this destination.</para>
- <para>
- This has been tested with in excess of 10 million 2K messages on very basic hardware
- and has the potential to scale to much larger number of messages.
- </para>
+ <para>Note that the security configuration for a destination is
+ optional. If a <literal>SecurityConfig</literal> element is not
+ specifed then the default security configuration from the Server
+ Peer will be used.</para>
+ </section>
- <para>
- The individual parameters are:
- </para>
-
- <para>
- <literal>FullSize</literal> - this is the maximum number of messages held by the
- queue or topic subscriptions in memory at any one time. The actual queue or
- subscription can hold many more messages than this but these are paged to and
- from storage as necessary as messages are added or consumed.
- </para>
-
- <para>
- <literal>PageSize</literal> - When loading messages from the queue or subscrition
- this is the maximum number of messages to pre-load in one operation.
- </para>
-
- <para>
- <literal>DownCacheSize</literal> - When paging messages to storage from the queue
- they first go into a "Down Cache" before being written to storage. This enables the
- write to occur as a single operation thus aiding performance. This setting determines
- the max number of messages that the Down Cache will hold before they are flushed
- to storage.
- </para>
+ <section id="conf.destination.queue.attributes.paging">
+ <title>Destination paging parameters</title>
- <para>
- If no values for <literal>FullSize</literal>, <literal>PageSize</literal>,
- or <literal>DownCacheSize</literal> are specified they will default to values
- 75000, 2000, 2000 respectively.
- </para>
+ <para>'Pageable Channels' are a sophisticated new feature available
+ in JBoss Messaging.</para>
- <para>
- If you want to specify the paging parameters used for temporary queues then you need to specify them
- on the appropriate connection factory.
- See connection factory configuration for details.
- </para>
- </section>
+ <para>If your application needs to support very large queues or
+ subscriptions containing potentially millions of messages, then it's
+ not possible to store them all in memory at once.</para>
- <section id="conf.destination.queue.attributes.createdprogrammatically">
- <title>CreatedProgrammatically</title>
+ <para>JBoss Messaging solves this problem but letting you specify
+ the maximum number of messages that can be stored in memory at any
+ one time, on a queue-by-queue, or topic-by-topic basis. JBoss
+ Messaging then pages messages to and from storage transparently in
+ blocks, allowing queues and subscriptions to grow to very large
+ sizes without any performance degradation as channel size
+ increases.</para>
- <para>
- Returns <literal>true</literal> if the queue was created programmatically
- </para>
- </section>
+ <para>This has been tested with in excess of 10 million 2K messages
+ on very basic hardware and has the potential to scale to much larger
+ number of messages.</para>
- <section id="conf.destination.queue.attributes.messagecount">
- <title>MessageCount</title>
+ <para>The individual parameters are:</para>
- <para>
- Returns the total number of messages in the queue = number not being delivered + number being delivered + number being scheduled
- </para>
- </section>
+ <para><literal>FullSize</literal> - this is the maximum number of
+ messages held by the queue or topic subscriptions in memory at any
+ one time. The actual queue or subscription can hold many more
+ messages than this but these are paged to and from storage as
+ necessary as messages are added or consumed.</para>
- <section id="conf.destination.queue.attributes.scheduledmessagecount">
- <title>ScheduledMessageCount</title>
+ <para><literal>PageSize</literal> - When loading messages from the
+ queue or subscrition this is the maximum number of messages to
+ pre-load in one operation.</para>
- <para>
- Returns the number of scheduled messages in the queue.
- This is the number of messages scheduled to be delivered at a later date.
- </para>
+ <para><literal>DownCacheSize</literal> - When paging messages to
+ storage from the queue they first go into a "Down Cache" before
+ being written to storage. This enables the write to occur as a
+ single operation thus aiding performance. This setting determines
+ the max number of messages that the Down Cache will hold before they
+ are flushed to storage.</para>
+
+ <para>If no values for <literal>FullSize</literal>,
+ <literal>PageSize</literal>, or <literal>DownCacheSize</literal> are
+ specified they will default to values 75000, 2000, 2000
+ respectively.</para>
+
+ <para>If you want to specify the paging parameters used for
+ temporary queues then you need to specify them on the appropriate
+ connection factory. See connection factory configuration for
+ details.</para>
+ </section>
+
+ <section id="conf.destination.queue.attributes.createdprogrammatically">
+ <title>CreatedProgrammatically</title>
+
+ <para>Returns <literal>true</literal> if the queue was created
+ programmatically</para>
+ </section>
+
+ <section id="conf.destination.queue.attributes.messagecount">
+ <title>MessageCount</title>
+
+ <para>Returns the total number of messages in the queue = number not
+ being delivered + number being delivered + number being
+ scheduled</para>
+ </section>
+
+ <section id="conf.destination.queue.attributes.scheduledmessagecount">
+ <title>ScheduledMessageCount</title>
+
+ <para>Returns the number of scheduled messages in the queue. This is
+ the number of messages scheduled to be delivered at a later
+ date.</para>
+
+ <para>Scheduled delivery is a feature of JBoss Messaging where you
+ can send a message and specify the earliest time at which it will be
+ delivered. E.g. you can send a message now, but the message won't
+ actually be delivered until 2 hours time.</para>
+
+ <para>To do this, you just need to set the following header in the
+ message before sending:</para>
+
+ <programlisting>
- <para>Scheduled delivery is a feature of JBoss Messaging where you can send a message and
- specify the earliest time at which it will be delivered.
- E.g. you can send a message now, but the message won't actually be delivered until 2 hours time.
- </para>
-
- <para>To do this, you just need to set the following header in the message before sending:</para>
-
- <programlisting>
-
long now = System.currentTimeMillis();
Message msg = sess.createMessage();
@@ -1701,534 +1636,465 @@
prod.send(msg);
</programlisting>
- </section>
+ </section>
- <section id="conf.destination.queue.attributes.maxsize">
- <title>MaxSize</title>
+ <section id="conf.destination.queue.attributes.maxsize">
+ <title>MaxSize</title>
- <para>
- A maximum size (in number of messages) can be specified for a queue. Any messages that arrive beyond this point will be dropped. The default is
- <literal>-1</literal> which is unbounded.
- </para>
- </section>
+ <para>A maximum size (in number of messages) can be specified for a
+ queue. Any messages that arrive beyond this point will be dropped.
+ The default is <literal>-1</literal> which is unbounded.</para>
+ </section>
- <section id="conf.destination.queue.attributes.clustered">
- <title>Clustered</title>
+ <section id="conf.destination.queue.attributes.clustered">
+ <title>Clustered</title>
- <para>
- Clustered destinations must have this set to <literal>true</literal>.
- </para>
- </section>
+ <para>Clustered destinations must have this set to
+ <literal>true</literal>.</para>
+ </section>
- <section id="conf.destination.queue.attributes.messagecounter">
- <title>MessageCounter</title>
+ <section id="conf.destination.queue.attributes.messagecounter">
+ <title>MessageCounter</title>
- <para>
- Each queue maintains a message counter.
- </para>
- </section>
+ <para>Each queue maintains a message counter.</para>
+ </section>
- <section id="conf.destination.queue.attributes.messagecounterstats">
- <title>MessageCounterStatistics</title>
+ <section id="conf.destination.queue.attributes.messagecounterstats">
+ <title>MessageCounterStatistics</title>
- <para>
- The statistics for the message counter
- </para>
- </section>
+ <para>The statistics for the message counter</para>
+ </section>
- <section id="conf.destination.queue.attributes.messagecounterhistorydaylimit">
- <title>MessageCounterHistoryDayLimit</title>
+ <section id="conf.destination.queue.attributes.messagecounterhistorydaylimit">
+ <title>MessageCounterHistoryDayLimit</title>
- <para>
- The maximum number of days to hold message counter history for. Overrides any value set on the ServerPeer.
- </para>
- </section>
+ <para>The maximum number of days to hold message counter history
+ for. Overrides any value set on the ServerPeer.</para>
+ </section>
- <section id="conf.destination.queue.attributes.consumercount">
- <title>ConsumerCount</title>
+ <section id="conf.destination.queue.attributes.consumercount">
+ <title>ConsumerCount</title>
- <para>
- The number of consumers currently consuming from the queue.
- </para>
- </section>
+ <para>The number of consumers currently consuming from the
+ queue.</para>
+ </section>
+ </section>
- </section>
+ <section id="conf.destination.queue.operations">
+ <title>We now discuss the MBean operations of the Queue MBean</title>
+ <section id="conf.destination.queue.operations.removeallmessages">
+ <title>RemoveAllMessages</title>
- <section id="conf.destination.queue.operations">
+ <para>Remove (and delete) all messages from the queue. <warning>
+ Use this with caution. It will permanently delete all messages from the queue
+ </warning>.</para>
+ </section>
- <title>
- We now discuss the MBean operations of the Queue MBean
- </title>
+ <section id="conf.destination.queue.operations.listallmessages">
+ <title>ListAllMessages</title>
- <section id="conf.destination.queue.operations.removeallmessages">
- <title>RemoveAllMessages</title>
-
- <para>
- Remove (and delete) all messages from the queue.
- <warning>Use this with caution. It will permanently delete all messages from the queue</warning>.
- </para>
- </section>
+ <para>List all messages currently in the queue</para>
- <section id="conf.destination.queue.operations.listallmessages">
- <title>ListAllMessages</title>
-
- <para>
- List all messages currently in the queue
- </para>
- <para>There are two overloaded versions of this operation: One takes a JMS selector as an argument, the other does not. By using the selector
- you can retrieve a subset of the messages in the queue that match the criteria</para>
- </section>
+ <para>There are two overloaded versions of this operation: One takes
+ a JMS selector as an argument, the other does not. By using the
+ selector you can retrieve a subset of the messages in the queue that
+ match the criteria</para>
+ </section>
- <section id="conf.destination.queue.operations.listdurablemessages">
- <title>ListDurableMessages</title>
+ <section id="conf.destination.queue.operations.listdurablemessages">
+ <title>ListDurableMessages</title>
- <para>
- As listAllMessages but only lists the durable messages
- </para>
- <para>There are two overloaded versions of this operation: One takes a JMS selector as an argument, the other does not. By using the selector
- you can retrieve a subset of the messages in the queue that match the criteria</para>
- </section>
+ <para>As listAllMessages but only lists the durable messages</para>
+ <para>There are two overloaded versions of this operation: One takes
+ a JMS selector as an argument, the other does not. By using the
+ selector you can retrieve a subset of the messages in the queue that
+ match the criteria</para>
+ </section>
- <section id="conf.destination.queue.operations.listnondurablemessages">
- <title>ListNonDurableMessages</title>
+ <section id="conf.destination.queue.operations.listnondurablemessages">
+ <title>ListNonDurableMessages</title>
- <para>
- As listAllMessages but only lists the non durable messages
- </para>
- <para>There are two overloaded versions of this operation: One takes a JMS selector as an argument, the other does not. By using the selector
- you can retrieve a subset of the messages in the queue that match the criteria</para>
- </section>
+ <para>As listAllMessages but only lists the non durable
+ messages</para>
- <section id="conf.destination.queue.operations.resetmessagecounter">
- <title>ResetMessageCounter</title>
+ <para>There are two overloaded versions of this operation: One takes
+ a JMS selector as an argument, the other does not. By using the
+ selector you can retrieve a subset of the messages in the queue that
+ match the criteria</para>
+ </section>
- <para>
- Resets the message counter to zero.
- </para>
- </section>
+ <section id="conf.destination.queue.operations.resetmessagecounter">
+ <title>ResetMessageCounter</title>
- <section id="conf.destination.queue.operations.resetmessagecounterhistory">
- <title>ResetMessageCounterHistory</title>
-
- <para>
- Resets the message counter history.
- </para>
- </section>
-
- <section id="conf.destination.queue.operations.listmessagecounterashtml">
- <title>ListMessageCounterAsHTML</title>
-
- <para>
- Lists the message counter in an easy to display HTML format
- </para>
- </section>
+ <para>Resets the message counter to zero.</para>
+ </section>
- <section id="conf.destination.queue.operations.listmessagecounterhistoryashtml">
- <title>ListMessageCounterHistoryAsHTML</title>
+ <section id="conf.destination.queue.operations.resetmessagecounterhistory">
+ <title>ResetMessageCounterHistory</title>
- <para>
- Lists the message counter history in an easy to display HTML format
- </para>
- </section>
+ <para>Resets the message counter history.</para>
+ </section>
- </section>
+ <section id="conf.destination.queue.operations.listmessagecounterashtml">
+ <title>ListMessageCounterAsHTML</title>
+ <para>Lists the message counter in an easy to display HTML
+ format</para>
</section>
- <section id="conf.destination.topics">
+ <section id="conf.destination.queue.operations.listmessagecounterhistoryashtml">
+ <title>ListMessageCounterHistoryAsHTML</title>
- <title>Configuring topics</title>
+ <para>Lists the message counter history in an easy to display HTML
+ format</para>
+ </section>
+ </section>
+ </section>
- <section id="conf.destination.topic.attributes">
+ <section id="conf.destination.topics">
+ <title>Configuring topics</title>
- <title>
- We now discuss the MBean attributes of the Topic MBean
- </title>
+ <section id="conf.destination.topic.attributes">
+ <title>We now discuss the MBean attributes of the Topic MBean</title>
- <section id="conf.destination.topic.attributes.name">
- <title>Name</title>
- <para>The name of the topic</para>
- </section>
+ <section id="conf.destination.topic.attributes.name">
+ <title>Name</title>
- <section id="conf.destination.topic.attributes.jndiName">
- <title>JNDIName</title>
- <para>The JNDI name where the topic is bound</para>
- </section>
+ <para>The name of the topic</para>
+ </section>
- <section id="conf.destination.topic.attributes.dlq">
- <title>DLQ</title>
- <para>The DLQ used for this topic. Overrides any value set on the ServerPeer config</para>
- </section>
+ <section id="conf.destination.topic.attributes.jndiName">
+ <title>JNDIName</title>
- <section id="conf.destination.topic.attributes.expiryqueue">
- <title>ExpiryQueue</title>
- <para>The Expiry queue used for this topic. Overrides any value set on the ServerPeer config</para>
- </section>
+ <para>The JNDI name where the topic is bound</para>
+ </section>
- <section id="conf.destination.topic.attributes.redeliverydelay">
- <title>RedeliveryDelay</title>
- <para>The redelivery delay to be used for this topic. Overrides any value set on the ServerPeer config</para>
- </section>
+ <section id="conf.destination.topic.attributes.dlq">
+ <title>DLQ</title>
- <section id="conf.destination.topic.attributes.maxdeliveryattempts">
- <title>MaxDeliveryAttempts</title>
- <para>
- The maximum number of times delivery of a message will be attempted before sending the message to the DLQ,
- if configured. If set to -1 (the default), the value from the ServerPeer config is used. Any other setting
- overrides the value set on the ServerPeer config.
- </para>
- </section>
+ <para>The DLQ used for this topic. Overrides any value set on the
+ ServerPeer config</para>
+ </section>
- <section id="conf.destination.topic.attributes.security">
- <title>Destination Security Configuration</title>
+ <section id="conf.destination.topic.attributes.expiryqueue">
+ <title>ExpiryQueue</title>
- <para>
- <literal>SecurityConfig</literal> - allows you to determine which roles are allowed
- to read, write and create on the destination. It has exactly the same syntax and
- semantics as the security configuration in JBossMQ destinations.
- </para>
+ <para>The Expiry queue used for this topic. Overrides any value set
+ on the ServerPeer config</para>
+ </section>
- <para>
- The <literal>SecurityConfig</literal> element should contain one
- <literal><security></literal> element. The <literal><security></literal>
- element can contain multiple <literal><role></literal> elements.
- Each <literal><role></literal> element defines the access for that
- particular role.
- </para>
+ <section id="conf.destination.topic.attributes.redeliverydelay">
+ <title>RedeliveryDelay</title>
- <para>
- If the <literal>read</literal> attribute is <literal>true</literal> then that role
- will be able to read (create consumers, receive messaages or browse) this destination.
- </para>
+ <para>The redelivery delay to be used for this topic. Overrides any
+ value set on the ServerPeer config</para>
+ </section>
- <para>
- If the <literal>write</literal> attribute is <literal>true</literal> then that role
- will be able to write (create producers or send messages) to this destination.
- </para>
+ <section id="conf.destination.topic.attributes.maxdeliveryattempts">
+ <title>MaxDeliveryAttempts</title>
- <para>
- If the <literal>create</literal> attribute is <literal>true</literal> then that role
- will be able to create durable subscriptions on this destination.
- </para>
+ <para>The maximum number of times delivery of a message will be
+ attempted before sending the message to the DLQ, if configured. If
+ set to -1 (the default), the value from the ServerPeer config is
+ used. Any other setting overrides the value set on the ServerPeer
+ config.</para>
+ </section>
- <para>
- Note that the security configuration for a destination is optional. If a
- <literal>SecurityConfig</literal> element is not specifed then the default
- security configuration from the Server Peer will be used.
- </para>
- </section>
+ <section id="conf.destination.topic.attributes.security">
+ <title>Destination Security Configuration</title>
- <section id="conf.destination.topic.attributes.paging">
- <title>Destination paging parameters</title>
+ <para><literal>SecurityConfig</literal> - allows you to determine
+ which roles are allowed to read, write and create on the
+ destination. It has exactly the same syntax and semantics as the
+ security configuration in JBossMQ destinations.</para>
- <para>
- 'Pageable Channels' are a sophisticated new feature available in JBoss Messaging.
- </para>
+ <para>The <literal>SecurityConfig</literal> element should contain
+ one <literal><security></literal> element. The
+ <literal><security></literal> element can contain multiple
+ <literal><role></literal> elements. Each
+ <literal><role></literal> element defines the access for that
+ particular role.</para>
- <para>
- If your application needs to support very large queues or subscriptions containing
- potentially millions of messages, then it's not possible to store them all in
- memory at once.
- </para>
+ <para>If the <literal>read</literal> attribute is
+ <literal>true</literal> then that role will be able to read (create
+ consumers, receive messaages or browse) this destination.</para>
- <para>
- JBoss Messaging solves this problem but letting you specify the
- maximum number of messages that can be stored in memory at any one time,
- on a queue-by-queue, or topic-by-topic basis. JBoss Messaging then pages messages
- to and from storage transparently in blocks, allowing queues and subscriptions to
- grow to very large sizes without any performance degradation as channel size increases.
- </para>
+ <para>If the <literal>write</literal> attribute is
+ <literal>true</literal> then that role will be able to write (create
+ producers or send messages) to this destination.</para>
- <para>
- This has been tested with in excess of 10 million 2K messages on very basic hardware
- and has the potential to scale to much larger number of messages.
- </para>
+ <para>If the <literal>create</literal> attribute is
+ <literal>true</literal> then that role will be able to create
+ durable subscriptions on this destination.</para>
- <para>
- The individual parameters are:
- </para>
+ <para>Note that the security configuration for a destination is
+ optional. If a <literal>SecurityConfig</literal> element is not
+ specifed then the default security configuration from the Server
+ Peer will be used.</para>
+ </section>
- <para>
- <literal>FullSize</literal> - this is the maximum number of messages held by the
- queue or topic subscriptions in memory at any one time. The actual queue or
- subscription can hold many more messages than this but these are paged to and
- from storage as necessary as messages are added or consumed.
- </para>
-
- <para>
- <literal>PageSize</literal> - When loading messages from the queue or subscrition
- this is the maximum number of messages to pre-load in one operation.
- </para>
+ <section id="conf.destination.topic.attributes.paging">
+ <title>Destination paging parameters</title>
- <para>
- <literal>DownCacheSize</literal> - When paging messages to storage from the queue
- they first go into a "Down Cache" before being written to storage. This enables the
- write to occur as a single operation thus aiding performance. This setting determines
- the max number of messages that the Down Cache will hold before they are flushed
- to storage.
- </para>
+ <para>'Pageable Channels' are a sophisticated new feature available
+ in JBoss Messaging.</para>
- <para>
- If no values for <literal>FullSize</literal>, <literal>PageSize</literal>,
- or <literal>DownCacheSize</literal> are specified they will default to values
- 75000, 2000, 2000 respectively.
- </para>
+ <para>If your application needs to support very large queues or
+ subscriptions containing potentially millions of messages, then it's
+ not possible to store them all in memory at once.</para>
- <para>
- If you want to specify the paging parameters used for temporary queues then you need to specify them
- on the appropriate connection factory.
- See connection factory configuration for details.
- </para>
- </section>
+ <para>JBoss Messaging solves this problem but letting you specify
+ the maximum number of messages that can be stored in memory at any
+ one time, on a queue-by-queue, or topic-by-topic basis. JBoss
+ Messaging then pages messages to and from storage transparently in
+ blocks, allowing queues and subscriptions to grow to very large
+ sizes without any performance degradation as channel size
+ increases.</para>
- <section id="conf.destination.topic.attributes.createdprogrammatically">
- <title>CreatedProgrammatically</title>
+ <para>This has been tested with in excess of 10 million 2K messages
+ on very basic hardware and has the potential to scale to much larger
+ number of messages.</para>
- <para>
- Returns <literal>true</literal> if the topic was created programmatically
- </para>
- </section>
+ <para>The individual parameters are:</para>
- <section id="conf.destination.topic.attributes.maxsize">
- <title>MaxSize</title>
+ <para><literal>FullSize</literal> - this is the maximum number of
+ messages held by the queue or topic subscriptions in memory at any
+ one time. The actual queue or subscription can hold many more
+ messages than this but these are paged to and from storage as
+ necessary as messages are added or consumed.</para>
- <para>
- A maximum size (in number of messages) can be specified for a topic subscription. Any messages that arrive beyond this point will be dropped. The default is
- <literal>-1</literal> which is unbounded.
- </para>
- </section>
+ <para><literal>PageSize</literal> - When loading messages from the
+ queue or subscrition this is the maximum number of messages to
+ pre-load in one operation.</para>
- <section id="conf.destination.topic.attributes.clustered">
- <title>Clustered</title>
-
- <para>
- Clustered destinations must have this set to <literal>true</literal>
- </para>
- </section>
+ <para><literal>DownCacheSize</literal> - When paging messages to
+ storage from the queue they first go into a "Down Cache" before
+ being written to storage. This enables the write to occur as a
+ single operation thus aiding performance. This setting determines
+ the max number of messages that the Down Cache will hold before they
+ are flushed to storage.</para>
- <section id="conf.destination.topic.attributes.messagecounterhistorydaylimit">
- <title>MessageCounterHistoryDayLimit</title>
+ <para>If no values for <literal>FullSize</literal>,
+ <literal>PageSize</literal>, or <literal>DownCacheSize</literal> are
+ specified they will default to values 75000, 2000, 2000
+ respectively.</para>
- <para>
- The maximum number of days to hold message counter history for. Overrides any value set on the ServerPeer.
- </para>
- </section>
+ <para>If you want to specify the paging parameters used for
+ temporary queues then you need to specify them on the appropriate
+ connection factory. See connection factory configuration for
+ details.</para>
+ </section>
- <section id="conf.destination.topic.attributes.messagecounters">
- <title>MessageCounters</title>
+ <section id="conf.destination.topic.attributes.createdprogrammatically">
+ <title>CreatedProgrammatically</title>
- <para>
- Return a list of the message counters for the subscriptions of this topic.
- </para>
- </section>
+ <para>Returns <literal>true</literal> if the topic was created
+ programmatically</para>
+ </section>
- <section id="conf.destination.topic.attributes.allmessagecount">
- <title>AllMessageCount</title>
+ <section id="conf.destination.topic.attributes.maxsize">
+ <title>MaxSize</title>
- <para>
- Return the total number of messages in all subscriptions of this topic.
- </para>
- </section>
+ <para>A maximum size (in number of messages) can be specified for a
+ topic subscription. Any messages that arrive beyond this point will
+ be dropped. The default is <literal>-1</literal> which is
+ unbounded.</para>
+ </section>
- <section id="conf.destination.topic.attributes.durablemessagecount">
- <title>DurableMessageCount</title>
-
- <para>
- Return the total number of durable messages in all subscriptions of this topic.
- </para>
-
- </section>
-
- <section id="conf.destination.topic.attributes.nondurablemessagecount">
- <title>NonDurableMessageCount</title>
-
- <para>
- Return the total number of non durable messages in all subscriptions of this topic.
- </para>
- </section>
+ <section id="conf.destination.topic.attributes.clustered">
+ <title>Clustered</title>
- <section id="conf.destination.topic.attributes.allsubscriptionscount">
- <title>AllSubscriptionsCount</title>
-
- <para>
- The count of all subscriptions on this topic
- </para>
- </section>
-
- <section id="conf.destination.topic.attributes.durablesubscriptionscount">
- <title>DurableSubscriptionsCount</title>
-
- <para>
- The count of all durable subscriptions on this topic
- </para>
- </section>
+ <para>Clustered destinations must have this set to
+ <literal>true</literal></para>
+ </section>
- <section id="conf.destination.topic.attributesnon.durablesubscriptionscount">
- <title>NonDurableSubscriptionsCount</title>
-
- <para>
- The count of all non durable subscriptions on this topic
- </para>
- </section>
+ <section id="conf.destination.topic.attributes.messagecounterhistorydaylimit">
+ <title>MessageCounterHistoryDayLimit</title>
- </section>
+ <para>The maximum number of days to hold message counter history
+ for. Overrides any value set on the ServerPeer.</para>
+ </section>
+ <section id="conf.destination.topic.attributes.messagecounters">
+ <title>MessageCounters</title>
- <section id="conf.destination.topic.operations">
+ <para>Return a list of the message counters for the subscriptions of
+ this topic.</para>
+ </section>
- <title>
- We now discuss the MBean operations of the Topic MBean
- </title>
-
- <section id="conf.destination.topic.operations.removeallmessages">
- <title>RemoveAllMessages</title>
-
- <para>
- Remove (and delete) all messages from the subscriptions of this topic.
- <warning>Use this with caution. It will permanently delete all messages from the topic</warning>
- </para>
- </section>
-
- <section id="conf.destination.topic.operations.listallsubscriptions">
- <title>ListAllSubscriptions</title>
-
- <para>
- List all subscriptions of this topic
- </para>
- </section>
-
- <section id="conf.destination.topic.operations.listdurablesubscriptions">
- <title>ListDurableSubscriptions</title>
-
- <para>
- List all durable subscriptions of this topic
- </para>
- </section>
+ <section id="conf.destination.topic.attributes.allmessagecount">
+ <title>AllMessageCount</title>
- <section id="conf.destination.topic.operations.listnondurablesubscriptions">
- <title>ListNonDurableSubscriptions</title>
-
- <para>
- List all non durable subscriptions of this topic
- </para>
- </section>
-
- <section id="conf.destination.topic.operations.listallsubscriptionsashtml">
- <title>ListAllSubscriptionsAsHTML</title>
-
- <para>
- List all subscriptions of this topic in an easy to display HTML format
- </para>
- </section>
+ <para>Return the total number of messages in all subscriptions of
+ this topic.</para>
+ </section>
- <section id="conf.destination.topic.operations.listdurablesubscriptionsashtml">
- <title>ListDurableSubscriptionsAsHTML</title>
-
- <para>
- List all durable subscriptions of this topic in an easy to display HTML format
- </para>
- </section>
-
- <section id="conf.destination.topic.operations.listnondurablesubscriptionsashtml">
- <title>ListNonDurableSubscriptionsAsHTML</title>
-
- <para>
- List all non durable subscriptions of this topic in an easy to display HTML format
- </para>
- </section>
-
- <section id="conf.destination.topic.operations.listallmessages">
- <title>ListAllMessages</title>
-
- <para>
- Lists all messages for the specified subscription.
- </para>
-
- <para> There are two overloaded versions of this operation. One that takes a selector and one that does not.
- By specifyingthe selector you can limit the messages returned.
- </para>
- </section>
+ <section id="conf.destination.topic.attributes.durablemessagecount">
+ <title>DurableMessageCount</title>
- <section id="conf.destination.topic.operations.listnondurablemessages">
- <title>ListNonDurableMessages</title>
-
- <para>
- Lists all non durable messages for the specified subscription.
- </para>
-
- <para> There are two overloaded versions of this operation. One that takes a selector and one that does not.
- By specifyingthe selector you can limit the messages returned.
- </para>
- </section>
-
- <section id="conf.destination.topic.operations.listdurablemessages">
- <title>ListDurableMessages</title>
-
- <para>
- Lists all durable messages for the specified subscription.
- </para>
-
- <para> There are two overloaded versions of this operation. One that takes a selector and one that does not.
- By specifyingthe selector you can limit the messages returned.
- </para>
- </section>
+ <para>Return the total number of durable messages in all
+ subscriptions of this topic.</para>
+ </section>
- </section>
+ <section id="conf.destination.topic.attributes.nondurablemessagecount">
+ <title>NonDurableMessageCount</title>
- </section>
-
- </section> <!-- end of conf destination -->
-
- <section id="conf.connectionfactory">
- <title>Configuring Connection Factories</title>
-
- <para>
- With the default configuration JBoss Messaging binds two connection factories in
- JNDI at start-up.
- </para>
- <para>
- The first connection factory is the default non-clustered connection factory and is bound into the
- following JNDI contexts:
- <literal>/ConnectionFactory, /XAConnectionFactory, java:/ConnectionFactory, java:/XAConnectionFactory</literal>.
- This connection factory is provided to maintain compatibility with applications originally written
- against JBoss MQ which has no automatic failover or load balancing.
- This connection factory should be used if you do not require client side automatic failover or
- load balancing.
- </para>
- <para>
- The second connection factory is the default clustered connection factory and is bound into the following
- JNDI contexts
- <literal>/ClusteredConnectionFactory, /ClusteredXAConnectionFactory, java:/ClusteredConnectionFactory, java:/ClusteredXAConnectionFactory</literal>.
-
- </para>
+ <para>Return the total number of non durable messages in all
+ subscriptions of this topic.</para>
+ </section>
- <para>
- You may want to configure additional connection factories, for instance if you want to provide
- a default client id for a connection factory, or if you want to bind it in different places
- in JNDI, if you want different connection factories to use different transports, or if you want
- to selective enable or disable load-balancing and/or automatic failover for a particular
- connection factory. Deploying
- a new connection factory is equivalent with adding a new ConnectionFactory MBean
- configuration to <filename>connection-factories-service.xml</filename>.
- </para>
- <para>
- It is also possible to create an entirely
- new service deployment descriptor <filename>xxx-service.xml</filename> altogether and
- deploy it in <filename>$JBOSS_HOME/server/messaging/deploy</filename>.
- </para>
+ <section id="conf.destination.topic.attributes.allsubscriptionscount">
+ <title>AllSubscriptionsCount</title>
- <para>
- Connection factories can support automatic failover and/or load-balancing by setting the corresponding
- attributes
- </para>
-
- <para>
- An example connection factory configuration is presented below:
- </para>
+ <para>The count of all subscriptions on this topic</para>
+ </section>
- <programlisting>
+ <section id="conf.destination.topic.attributes.durablesubscriptionscount">
+ <title>DurableSubscriptionsCount</title>
+
+ <para>The count of all durable subscriptions on this topic</para>
+ </section>
+
+ <section id="conf.destination.topic.attributesnon.durablesubscriptionscount">
+ <title>NonDurableSubscriptionsCount</title>
+
+ <para>The count of all non durable subscriptions on this
+ topic</para>
+ </section>
+ </section>
+
+ <section id="conf.destination.topic.operations">
+ <title>We now discuss the MBean operations of the Topic MBean</title>
+
+ <section id="conf.destination.topic.operations.removeallmessages">
+ <title>RemoveAllMessages</title>
+
+ <para>Remove (and delete) all messages from the subscriptions of
+ this topic. <warning>
+ Use this with caution. It will permanently delete all messages from the topic
+ </warning></para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listallsubscriptions">
+ <title>ListAllSubscriptions</title>
+
+ <para>List all subscriptions of this topic</para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listdurablesubscriptions">
+ <title>ListDurableSubscriptions</title>
+
+ <para>List all durable subscriptions of this topic</para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listnondurablesubscriptions">
+ <title>ListNonDurableSubscriptions</title>
+
+ <para>List all non durable subscriptions of this topic</para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listallsubscriptionsashtml">
+ <title>ListAllSubscriptionsAsHTML</title>
+
+ <para>List all subscriptions of this topic in an easy to display
+ HTML format</para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listdurablesubscriptionsashtml">
+ <title>ListDurableSubscriptionsAsHTML</title>
+
+ <para>List all durable subscriptions of this topic in an easy to
+ display HTML format</para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listnondurablesubscriptionsashtml">
+ <title>ListNonDurableSubscriptionsAsHTML</title>
+
+ <para>List all non durable subscriptions of this topic in an easy to
+ display HTML format</para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listallmessages">
+ <title>ListAllMessages</title>
+
+ <para>Lists all messages for the specified subscription.</para>
+
+ <para>There are two overloaded versions of this operation. One that
+ takes a selector and one that does not. By specifyingthe selector
+ you can limit the messages returned.</para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listnondurablemessages">
+ <title>ListNonDurableMessages</title>
+
+ <para>Lists all non durable messages for the specified
+ subscription.</para>
+
+ <para>There are two overloaded versions of this operation. One that
+ takes a selector and one that does not. By specifyingthe selector
+ you can limit the messages returned.</para>
+ </section>
+
+ <section id="conf.destination.topic.operations.listdurablemessages">
+ <title>ListDurableMessages</title>
+
+ <para>Lists all durable messages for the specified
+ subscription.</para>
+
+ <para>There are two overloaded versions of this operation. One that
+ takes a selector and one that does not. By specifyingthe selector
+ you can limit the messages returned.</para>
+ </section>
+ </section>
+ </section>
+ </section>
+
+ <!-- end of conf destination -->
+
+ <section id="conf.connectionfactory">
+ <title>Configuring Connection Factories</title>
+
+ <para>With the default configuration JBoss Messaging binds two connection
+ factories in JNDI at start-up.</para>
+
+ <para>The first connection factory is the default non-clustered connection
+ factory and is bound into the following JNDI contexts:
+ <literal>/ConnectionFactory, /XAConnectionFactory,
+ java:/ConnectionFactory, java:/XAConnectionFactory</literal>. This
+ connection factory is provided to maintain compatibility with applications
+ originally written against JBoss MQ which has no automatic failover or
+ load balancing. This connection factory should be used if you do not
+ require client side automatic failover or load balancing.</para>
+
+ <para>The second connection factory is the default clustered connection
+ factory and is bound into the following JNDI contexts
+ <literal>/ClusteredConnectionFactory, /ClusteredXAConnectionFactory,
+ java:/ClusteredConnectionFactory,
+ java:/ClusteredXAConnectionFactory</literal>.</para>
+
+ <para>You may want to configure additional connection factories, for
+ instance if you want to provide a default client id for a connection
+ factory, or if you want to bind it in different places in JNDI, if you
+ want different connection factories to use different transports, or if you
+ want to selective enable or disable load-balancing and/or automatic
+ failover for a particular connection factory. Deploying a new connection
+ factory is equivalent with adding a new ConnectionFactory MBean
+ configuration to
+ <filename>connection-factories-service.xml</filename>.</para>
+
+ <para>It is also possible to create an entirely new service deployment
+ descriptor <filename>xxx-service.xml</filename> altogether and deploy it
+ in <filename>$JBOSS_HOME/server/messaging/deploy</filename>.</para>
+
+ <para>Connection factories can support automatic failover and/or
+ load-balancing by setting the corresponding attributes</para>
+
+ <para>An example connection factory configuration is presented
+ below:</para>
+
+ <programlisting>
<mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"
name="jboss.messaging.connectionfactory:service=MyConnectionFactory"
xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
@@ -2273,251 +2139,256 @@
</programlisting>
- <para>
- The above example would create a connection factory with pre-configured client ID
- <literal>myClientID</literal> and bind the connection factory in two places in
- the JNDI tree: <literal>/MyConnectionFactory</literal>
- and <literal>/factories/cf</literal>.
- The connection factory overrides the default values for PreFetchSize,
- DefaultTempQueueFullSize, DefaultTempQueuePageSize, DefaultTempQueueDownCacheSize and
- DupsOKBatchSize, SupportsFailover, SupportsLoadBalancing and LoadBalancingFactory.
- 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>
+ <para>The above example would create a connection factory with
+ pre-configured client ID <literal>myClientID</literal> and bind the
+ connection factory in two places in the JNDI tree:
+ <literal>/MyConnectionFactory</literal> and
+ <literal>/factories/cf</literal>. The connection factory overrides the
+ default values for PreFetchSize, DefaultTempQueueFullSize,
+ DefaultTempQueuePageSize, DefaultTempQueueDownCacheSize and
+ DupsOKBatchSize, SupportsFailover, SupportsLoadBalancing and
+ LoadBalancingFactory. 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>
- <section id="conf.connectionfactory.attributes">
+ <section id="conf.connectionfactory.attributes">
+ <title>We now discuss the MBean attributes of the ConnectionFactory
+ MBean</title>
- <title>
- We now discuss the MBean attributes of the ConnectionFactory MBean
- </title>
-
- <section id="conf.connectionfactory.attributes.clientid">
- <title>ClientID</title>
-
- <para>
- Connection factories can be pre-configured with a client id. Any connections created using this connection factory will obtain this client id
- </para>
- </section>
-
- <section id="conf.connectionfactory.attributes.jndibindings">
- <title>JNDIBindings</title>
-
- <para>
- The list of the JNDI bindings for this connection factory
- </para>
- </section>
+ <section id="conf.connectionfactory.attributes.clientid">
+ <title>ClientID</title>
- <section id="conf.connectionfactory.attributes.prefetchsize">
- <title>PrefetchSize</title>
-
- <para>
- Each client side consumer maintains a local buffer of messages from which it consumes. The server typically sends messages as fast as it can
- to the consumer, and when the consumer is full it sends the server a "stop" message to say it is full.
- When it clears enough space it sends a "start" message to ask the server to continue sending messages.
- The prefetchSize determines the size of this buffer. Larger values give better throughput.
- </para>
- </section>
+ <para>Connection factories can be pre-configured with a client id. Any
+ connections created using this connection factory will obtain this
+ client id</para>
+ </section>
- <section id="conf.connectionfactory.attributes.slowconsumers">
- <title>SlowConsumers</title>
-
- <para>
- If you have very slow consumers, then you probably want to make sure they don't buffer any messages.
- Since this can prevent them from being consumed by faster consumers.
- </para>
- </section>
+ <section id="conf.connectionfactory.attributes.jndibindings">
+ <title>JNDIBindings</title>
- <section id="conf.connectionfactory.attributes.tckstrictbehavior">
- <title>StrictTck</title>
- <para>
- As part of JMS specification foreign messages should receive a new destination when the message is sent, but when the Bridge is playing with other providers
- such as ActiveMQ this could affect the regular operation on those providers. We disabled that by default but if you need this behavior activated you should just set this attribute to
- True on the ConnectionFactory.
- </para>
- </section>
+ <para>The list of the JNDI bindings for this connection factory</para>
+ </section>
- <section id="conf.connectionfactory.attributes.tempqueuepaging">
- <title>Temporary queue paging parameters</title>
-
- <para>DefaultTempQueueFullSize, DefaultTempQueuePageSize, DefaultTempQueueDownCacheSize are optional attributes that determine the default paging parameters to be used for
- any temporary destinations scoped to connections created using this connection factory. See the section on paging channels for more information
- on what these values mean.
- They will default to values of 200000, 2000 and 2000 respectively if ommitted.
- </para>
- </section>
-
- <section id="conf.connectionfactory.attributes.dupsokbatchsize">
- <title>DupsOKBatchSize</title>
-
- <para>When using a session with acknowledge mode of DUPS_OK_ACKNOWLEDGE this setting determines how many acknowledgments it will buffer locally
- before sending. The default value is <literal>2000</literal>
- </para>
- </section>
-
- <section id="conf.connectionfactory.attributes.supportsloadbalancing">
- <title>SupportsLoadBalancing</title>
-
- <para>When using a connection factory with a clustered JBoss Messaging installation you can choose whether
- to enable client side connection load-balancing. This is determined by setting the attribute supportsLoadBalancing on the connection
- factory.
- </para>
-
- <para>If load balancing is enabled on a connection factory then any connections created with that connection factory will
- be load-balanced across the nodes of the cluster. Once a connection is created on a particular node, it stays on that node.
- </para>
-
- <para>The exact policy that determines how connections are load balanced is determined by the LoadBalancingFactory attribute</para>
-
- <para>
- The default value is <literal>false</literal>
- </para>
- </section>
-
- <section id="conf.connectionfactory.attributes.supportsfailover">
- <title>SupportsFailover</title>
-
- <para>When using a connection factory with a clustered JBoss Messaging installation you can choose whether
- to enable client side automatic failover. This is determined by setting the attribute supportsFailover on the connection
- factory.
- </para>
-
- <para>If automatic failover is enabled on a connection factory, then if a connection problem is detected with the connection then
- JBoss Messaging will automatically and transparently failover to another node in the cluster.
- </para>
-
- <para>The failover is transparent meaning the user can carry on using the sessions, consumers, producers and connection objects
- as before.
- </para>
-
- <para>If automatic failover is not required, then this attribute can be set to false. With automatic failover disabled it is up
- to the user code to catch connection exceptions in synchronous JMS operations and install a JMS ExceptionListener to catch
- exceptions asynchronously. When a connection is caught, the client side code should lookup a new connection factory using HAJNDI
- and recreate the connection using that.
- </para>
-
- <para>
- The default value is <literal>false</literal>
- </para>
- </section>
-
- <section id="conf.connectionfactory.attributes.loadbalancingfactory">
- <title>LoadBalancingFactory</title>
-
- <para>If you are using a connection factory with client side load balancing then you can specify how the load balancing
- is implemented by overriding this attribute. The value must correspond to the name of a class which implements the interface
- org.jboss.jms.client.plugin.LoadBalancingFactory
- </para>
-
- <para>The default value is org.jboss.jms.client.plugin.RoundRobinLoadBalancingFactory, which load balances connetions across
- the cluster in a round-robin fashion
- </para>
-
- </section>
+ <section id="conf.connectionfactory.attributes.prefetchsize">
+ <title>PrefetchSize</title>
- <section id="conf.connectionfactory.attributes.connector">
- <title>Connector</title>
-
- <para>This specifies which remoting connector this connection factory uses. Different connection factories can use different connectors.
- </para>
- <para>For instance you could deploy one connection factory that creates connections that use the HTTP transport to communicate to the server and another
- that creates connections that use the bisocket transport to communicate.</para>
- </section>
- </section> <!-- End conf.connectionfactory.attributes -->
- </section> <!-- End conf.connectionfactory -->
+ <para>Each client side consumer maintains a local buffer of messages
+ from which it consumes. The server typically sends messages as fast as
+ it can to the consumer, and when the consumer is full it sends the
+ server a "stop" message to say it is full. When it clears enough space
+ it sends a "start" message to ask the server to continue sending
+ messages. The prefetchSize determines the size of this buffer. Larger
+ values give better throughput.</para>
+ </section>
+ <section id="conf.connectionfactory.attributes.slowconsumers">
+ <title>SlowConsumers</title>
- <section id="conf.connector">
- <title>Configuring the remoting connector</title>
-
- <para>
- JBoss Messaging uses JBoss Remoting for all client to server communication.
- For full details of what JBoss Remoting is capable of and how it is configured please
- consult the JBoss Remoting documentation.
- </para>
-
- <para>
- The default configuration includes a single remoting connector which is used by the
- single default connection factory. Each connection factory can be configured to use
- its own connector.
- </para>
-
- <para>
- The default connector is configured to use the remoting bisocket transport. The bisocket transport is a TCP socket based transport
- which only listens and accepts connections on the server side. I.e. connections are always initiated from the client side. This means
- it works well in typical firewall scenarios where only inbound connections are allowed on the server. Or where onlu outbound connections are
- allowed from the client.
- </para>
+ <para>If you have very slow consumers, then you probably want to make
+ sure they don't buffer any messages. Since this can prevent them from
+ being consumed by faster consumers.</para>
+ </section>
- <para>
- The bisocket transport can be configured to use SSL where a higher level of security is required.
- </para>
-
- <para>
- The other supported transport is the HTTP transport. This uses the HTTP protocol to communicate between client and server. Data is received on the client
- by the client periodically polling the server for messages. This transport is well suited to situations where there is a firewall between client and server
- which only allows incoming HTTP traffic on the server.
- Please note this transport will not be as performant as the bisocket transport due to the nature of polling and the HTTP protocl. Also please note it is not
- designed for high load situations.
- </para>
-
- <para>No other remoting transports are currently supported by JBoss Messaging</para>
-
- <para>
- You can look at remoting configuration under:
- </para>
-
- <para>
- <JBoss>/server/<YourMessagingServer>/deploy/jboss-messaging.sar/remoting-bisocket-service.xml
- </para>
-
- <para>
- By default JBoss Messaging binds to ${jboss.bind.address} which can be defined by:
- ./run.sh -c <yourconfig> -b yourIP.
- </para>
-
- <para>
- You can change remoting-bisocket-service.xml if you want for example use a
- different communication port.
- </para>
-
- <warning>Please be wary of changing other settings as they can have an adverse effect on the system</warning>
+ <section id="conf.connectionfactory.attributes.tckstrictbehavior">
+ <title>StrictTck</title>
- </section> <!-- end conf.connector -->
+ <para>As part of JMS specification foreign messages should receive a
+ new destination when the message is sent, but when the Bridge is
+ playing with other providers such as ActiveMQ this could affect the
+ regular operation on those providers. We disabled that by default but
+ if you need this behavior activated you should just set this attribute
+ to True on the ConnectionFactory.</para>
+ </section>
- <section id="conf.servicebindingmanager">
- <title>ServiceBindingManager</title>
-
- <para>If you are using the JBoss AS ServiceBindingManager to provide different servers with different port ranges, then you must make sure that the JBoss Messaging
- remoting configuration specified in the JBoss Messaging section of the ServiceBindingManager xml file exactly matches that in remoting-bisocket-service.xml
- </para>
-
- <para>See the chapter on installation for a description of how to set-up the service binding manager for
- JBoss Messaging</para>
-
- </section>
+ <section id="conf.connectionfactory.attributes.tempqueuepaging">
+ <title>Temporary queue paging parameters</title>
+ <para>DefaultTempQueueFullSize, DefaultTempQueuePageSize,
+ DefaultTempQueueDownCacheSize are optional attributes that determine
+ the default paging parameters to be used for any temporary
+ destinations scoped to connections created using this connection
+ factory. See the section on paging channels for more information on
+ what these values mean. They will default to values of 200000, 2000
+ and 2000 respectively if ommitted.</para>
+ </section>
- <section id="conf.callback">
- <title>Configuring the callback</title>
-
- <para>
- JBoss Messaging uses a callback mechanism from Remoting that needs a Socket for callback operations. These socket properties are passed to the server by a remote call when the connection is being estabilished. As we said before we will support bidirectional protocols in future releases.
- </para>
-
- <para>
- By default JBoss Messaging will execute InetAddress.getLocalHost().getHostAddress() to access your local host IP, but in case you need to setup a different IP, you can define a system property in your java arguments:
- </para>
-
- <para>
- Use java -Djboss.messaging.callback.bind.address=YourHost - That will determine the callBack host in your client.
- </para>
-
- <para>
- The client port will be selected randomly for any non used port. But if you defined -Djboss.messaging.callback.bind.port=NumericPort in your System Properties that number is going to be used for the call back client port.
- </para>
+ <section id="conf.connectionfactory.attributes.dupsokbatchsize">
+ <title>DupsOKBatchSize</title>
- </section> <!-- End conf.callback -->
-
-
-</chapter>
+ <para>When using a session with acknowledge mode of
+ DUPS_OK_ACKNOWLEDGE this setting determines how many acknowledgments
+ it will buffer locally before sending. The default value is
+ <literal>2000</literal></para>
+ </section>
+
+ <section id="conf.connectionfactory.attributes.supportsloadbalancing">
+ <title>SupportsLoadBalancing</title>
+
+ <para>When using a connection factory with a clustered JBoss Messaging
+ installation you can choose whether to enable client side connection
+ load-balancing. This is determined by setting the attribute
+ supportsLoadBalancing on the connection factory.</para>
+
+ <para>If load balancing is enabled on a connection factory then any
+ connections created with that connection factory will be load-balanced
+ across the nodes of the cluster. Once a connection is created on a
+ particular node, it stays on that node.</para>
+
+ <para>The exact policy that determines how connections are load
+ balanced is determined by the LoadBalancingFactory attribute</para>
+
+ <para>The default value is <literal>false</literal></para>
+ </section>
+
+ <section id="conf.connectionfactory.attributes.supportsfailover">
+ <title>SupportsFailover</title>
+
+ <para>When using a connection factory with a clustered JBoss Messaging
+ installation you can choose whether to enable client side automatic
+ failover. This is determined by setting the attribute supportsFailover
+ on the connection factory.</para>
+
+ <para>If automatic failover is enabled on a connection factory, then
+ if a connection problem is detected with the connection then JBoss
+ Messaging will automatically and transparently failover to another
+ node in the cluster.</para>
+
+ <para>The failover is transparent meaning the user can carry on using
+ the sessions, consumers, producers and connection objects as
+ before.</para>
+
+ <para>If automatic failover is not required, then this attribute can
+ be set to false. With automatic failover disabled it is up to the user
+ code to catch connection exceptions in synchronous JMS operations and
+ install a JMS ExceptionListener to catch exceptions asynchronously.
+ When a connection is caught, the client side code should lookup a new
+ connection factory using HAJNDI and recreate the connection using
+ that.</para>
+
+ <para>The default value is <literal>false</literal></para>
+ </section>
+
+ <section id="conf.connectionfactory.attributes.loadbalancingfactory">
+ <title>LoadBalancingFactory</title>
+
+ <para>If you are using a connection factory with client side load
+ balancing then you can specify how the load balancing is implemented
+ by overriding this attribute. The value must correspond to the name of
+ a class which implements the interface
+ org.jboss.jms.client.plugin.LoadBalancingFactory</para>
+
+ <para>The default value is
+ org.jboss.jms.client.plugin.RoundRobinLoadBalancingFactory, which load
+ balances connetions across the cluster in a round-robin fashion</para>
+ </section>
+
+ <section id="conf.connectionfactory.attributes.connector">
+ <title>Connector</title>
+
+ <para>This specifies which remoting connector this connection factory
+ uses. Different connection factories can use different
+ connectors.</para>
+
+ <para>For instance you could deploy one connection factory that
+ creates connections that use the HTTP transport to communicate to the
+ server and another that creates connections that use the bisocket
+ transport to communicate.</para>
+ </section>
+ </section>
+
+ <!-- End conf.connectionfactory.attributes -->
+ </section>
+
+ <!-- End conf.connectionfactory -->
+
+ <section id="conf.connector">
+ <title>Configuring the remoting connector</title>
+
+ <para>JBoss Messaging uses JBoss Remoting for all client to server
+ communication. For full details of what JBoss Remoting is capable of and
+ how it is configured please consult the JBoss Remoting
+ documentation.</para>
+
+ <para>The default configuration includes a single remoting connector which
+ is used by the single default connection factory. Each connection factory
+ can be configured to use its own connector.</para>
+
+ <para>The default connector is configured to use the remoting bisocket
+ transport. The bisocket transport is a TCP socket based transport which
+ only listens and accepts connections on the server side. I.e. connections
+ are always initiated from the client side. This means it works well in
+ typical firewall scenarios where only inbound connections are allowed on
+ the server. Or where onlu outbound connections are allowed from the
+ client.</para>
+
+ <para>The bisocket transport can be configured to use SSL where a higher
+ level of security is required.</para>
+
+ <para>The other supported transport is the HTTP transport. This uses the
+ HTTP protocol to communicate between client and server. Data is received
+ on the client by the client periodically polling the server for messages.
+ This transport is well suited to situations where there is a firewall
+ between client and server which only allows incoming HTTP traffic on the
+ server. Please note this transport will not be as performant as the
+ bisocket transport due to the nature of polling and the HTTP protocl. Also
+ please note it is not designed for high load situations.</para>
+
+ <para>No other remoting transports are currently supported by JBoss
+ Messaging</para>
+
+ <para>You can look at remoting configuration under:</para>
+
+ <para><JBoss>/server/<YourMessagingServer>/deploy/jboss-messaging.sar/remoting-bisocket-service.xml</para>
+
+ <para>By default JBoss Messaging binds to ${jboss.bind.address} which can
+ be defined by: ./run.sh -c <yourconfig> -b yourIP.</para>
+
+ <para>You can change remoting-bisocket-service.xml if you want for example
+ use a different communication port.</para>
+
+ <warning>
+ Please be wary of changing other settings as they can have an adverse effect on the system
+ </warning>
+ </section>
+
+ <!-- end conf.connector -->
+
+ <section id="conf.servicebindingmanager">
+ <title>ServiceBindingManager</title>
+
+ <para>If you are using the JBoss AS ServiceBindingManager to provide
+ different servers with different port ranges, then you must make sure that
+ the JBoss Messaging remoting configuration specified in the JBoss
+ Messaging section of the ServiceBindingManager xml file exactly matches
+ that in remoting-bisocket-service.xml</para>
+
+ <para>See the chapter on installation for a description of how to set-up
+ the service binding manager for JBoss Messaging</para>
+ </section>
+
+ <section id="conf.callback">
+ <title>Configuring the callback</title>
+
+ <para>JBoss Messaging uses a callback mechanism from Remoting that needs a
+ Socket for callback operations. These socket properties are passed to the
+ server by a remote call when the connection is being estabilished. As we
+ said before we will support bidirectional protocols in future
+ releases.</para>
+
+ <para>By default JBoss Messaging will execute
+ InetAddress.getLocalHost().getHostAddress() to access your local host IP,
+ but in case you need to setup a different IP, you can define a system
+ property in your java arguments:</para>
+
+ <para>Use java -Djboss.messaging.callback.bind.address=YourHost - That
+ will determine the callBack host in your client.</para>
+
+ <para>The client port will be selected randomly for any non used port. But
+ if you defined -Djboss.messaging.callback.bind.port=NumericPort in your
+ System Properties that number is going to be used for the call back client
+ port.</para>
+ </section>
+
+ <!-- End conf.callback -->
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/gettingstarted.xml
===================================================================
--- trunk/docs/userguide/en/modules/gettingstarted.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/gettingstarted.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -1,96 +1,127 @@
+<?xml version="1.0" encoding="UTF-8"?>
<chapter id="gettingstarted">
- <title>Download Software</title>
+ <title>Download Software</title>
- <para>
- The official JBoss Messaging project page is
- <ulink url="http://labs.jboss.com/jbossmessaging">http://labs.jboss.com/jbossmessaging/</ulink>.
- </para>
+ <para>The official JBoss Messaging project page is <ulink
+ url="http://labs.jboss.com/jbossmessaging">http://labs.jboss.com/jbossmessaging/</ulink>.</para>
- <para>
- The download location is the JBoss Labs Messaging Project download zone:
- <ulink url="http://labs.jboss.com/jbossmessaging/">http://labs.jboss.com/jbossmessaging/</ulink>
- </para>
+ <para>The download location is the JBoss Labs Messaging Project download
+ zone: <ulink
+ url="http://labs.jboss.com/jbossmessaging/">http://labs.jboss.com/jbossmessaging/</ulink></para>
- <section id="releasebundle">
- <title>The JBoss Messaging Release Bundle</title>
+ <section id="releasebundle">
+ <title>The JBoss Messaging Release Bundle</title>
- <para>
- The JBoss Messaging release bundle (<filename>jboss-messaging-1.4.x.zip</filename>)
- will expand in a <filename>jboss-messaging-1.4.x</filename> directory that contains:
- </para>
+ <para>The JBoss Messaging release bundle
+ (<filename>jboss-messaging-1.4.x.zip</filename>) will expand in a
+ <filename>jboss-messaging-1.4.x</filename> directory that contains:</para>
- <itemizedlist>
- <listitem>
- <filename>jboss-messaging.sar</filename>
- - the service archive that contains JBoss Messaging configuration
- <warning>
- Do not simply attempt to copy the archive under a JBoss instance <filename>deploy</filename> directory,
- since additional steps (such as un-installing JBossMQ and various other configurations
- tasks) are required for a successful installation. See <xref linkend="installation"/> for
- more details.
- </warning>
- </listitem>
- <listitem>
- <filename>jboss-messaging.jar</filename>
- - the JBoss Messaging jar file
- </listitem>
- <listitem>
- <filename>jboss-messaging-client.jar</filename>
- - the client-side library that need to be in the classpath of the client that opens
- a remote connection to the Messaging server.
- </listitem>
- <listitem>
- <filename>util</filename>
- - a collection of <literal>ant</literal> configuration files used to automate
- installation. See <xref linkend="installation"/> for more details.
- </listitem>
- <listitem>
- <filename>examples</filename>
- - a collection of examples that should run out of the box and help you validate the
- installation. Detailed instructions are provided with each example, which range from
- very simple JMS queue and topic examples to EJB 2.1, EJB3 and clustering examples.
- The <filename>examples/config</filename> sub-directory contains various configuration
- file examples.
- </listitem>
- <listitem>
- <filename>docs</filename>
- - this user's guide.
- </listitem>
- <listitem>
- <filename>test-results</filename>
- - the output of the functional testsuite, stress and smoke test runs for this release.
- All these files have been generated during the release procedure and are bundled here
- for reference.
- </listitem>
- <listitem>
- <filename>api</filename>
- - the Messaging API javadoc.
- </listitem>
- <listitem>
- <filename>README.html</filename>
- - The release intro document that contains pointers to various other resources,
- including this Guide.
- </listitem>
- </itemizedlist>
+ <itemizedlist>
+ <listitem>
+
- </section>
+ <filename>jboss-messaging.sar</filename>
+ - the service archive that contains JBoss Messaging configuration
- <section id="SVN">
- <title>SVN Access</title>
+ <warning>Do not simply attempt to copy the archive under a JBoss
+ instance <filename>deploy</filename> directory, since additional steps
+ (such as un-installing JBossMQ and various other configurations tasks)
+ are required for a successful installation. See <xref
+ linkend="installation" /> for more details.</warning>
- <para>
- If you want to experiment with the latest developments you may checkout the latest code
- from the Messaging SVN trunk. Be aware that the information provided in this manual might
- then not be accurate.
- For the latest instructions on how to check out and build source code, please go to
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingDevelopment">
- Messaging Development wiki page</ulink>, specifically
+
+ </listitem>
- <ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingBuildInstructions">
- "Building and Running JBoss Messaging"</ulink> section.
- </para>
+ <listitem>
+
- </section>
+ <filename>jboss-messaging.jar</filename>
-</chapter>
+ - the JBoss Messaging jar file
+ </listitem>
+
+ <listitem>
+
+
+ <filename>jboss-messaging-client.jar</filename>
+
+ - the client-side library that need to be in the classpath of the client that opens a remote connection to the Messaging server.
+ </listitem>
+
+ <listitem>
+
+
+ <filename>util</filename>
+
+ - a collection of
+
+ <literal>ant</literal>
+
+ configuration files used to automate installation. See
+
+ <xref linkend="installation" />
+
+ for more details.
+ </listitem>
+
+ <listitem>
+
+
+ <filename>examples</filename>
+
+ - a collection of examples that should run out of the box and help you validate the installation. Detailed instructions are provided with each example, which range from very simple JMS queue and topic examples to EJB 2.1, EJB3 and clustering examples. The
+
+ <filename>examples/config</filename>
+
+ sub-directory contains various configuration file examples.
+ </listitem>
+
+ <listitem>
+
+
+ <filename>docs</filename>
+
+ - this user's guide.
+ </listitem>
+
+ <listitem>
+
+
+ <filename>test-results</filename>
+
+ - the output of the functional testsuite, stress and smoke test runs for this release. All these files have been generated during the release procedure and are bundled here for reference.
+ </listitem>
+
+ <listitem>
+
+
+ <filename>api</filename>
+
+ - the Messaging API javadoc.
+ </listitem>
+
+ <listitem>
+
+
+ <filename>README.html</filename>
+
+ - The release intro document that contains pointers to various other resources, including this Guide.
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section id="SVN">
+ <title>SVN Access</title>
+
+ <para>If you want to experiment with the latest developments you may
+ checkout the latest code from the Messaging SVN trunk. Be aware that the
+ information provided in this manual might then not be accurate. For the
+ latest instructions on how to check out and build source code, please go
+ to <ulink
+ url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingDevelopment">
+ Messaging Development wiki page</ulink>, specifically <ulink
+ url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingBuildInstructions">
+ "Building and Running JBoss Messaging"</ulink> section.</para>
+ </section>
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/installation.xml
===================================================================
--- trunk/docs/userguide/en/modules/installation.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/installation.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -7,168 +7,181 @@
Messaging configuration that will start a clustered or non-clustered
messaging server.</para>
- <para>By default, JBoss AS 4.2.0 instance ships with JBossMQ as
- default JMS provider. In order to use the JBoss AS instance with JBoss
- Messaging, you need to perform the installation procedure described
- below.</para>
+ <para>By default, JBoss AS 4.2.0 instance ships with JBossMQ as default JMS
+ provider. In order to use the JBoss AS instance with JBoss Messaging, you
+ need to perform the installation procedure described below.</para>
- <para>
- <note>
- A JBossMQ and a JBoss Messaging instance cannot coexist, at least not unless special precautions are taken.
- Do not simply attempt to copy the Messaging release artifact
+ <para><note>
+ A JBossMQ and a JBoss Messaging instance cannot coexist, at least not unless special precautions are taken. Do not simply attempt to copy the Messaging release artifact
<filename>jboss-messaging.sar</filename>
- over to the JBoss instance w
+ over to the JBoss instance w
<filename>deploy</filename>
directory. Follow one of the alternate installation procedures outlined below instead.
- </note>
- </para>
-
- <para>
- <note>
- We only recommend and support installing JBoss Messaging in JBoss AS 4.2 or later.
- You should avoid using JBoss Messaging on any version of JBoss AS prior to JBoss 4.2.0.GA,
- such as 4.0.5.GA and 4.0.4.GA.
- </note>
- <note>JBoss Messaging is built against the JBoss AS 4.2 libraries which are built using Java 5. Therefore JBoss Messaging
- only runs with Java 5 or later.</note>
- </para>
+ </note></para>
+ <para><note>
+ We only recommend and support installing JBoss Messaging in JBoss AS 4.2 or later. You should avoid using JBoss Messaging on any version of JBoss AS prior to JBoss 4.2.0.GA, such as 4.0.5.GA and 4.0.4.GA.
+ </note> <note>
+ JBoss Messaging is built against the JBoss AS 4.2 libraries which are built using Java 5. Therefore JBoss Messaging only runs with Java 5 or later.
+ </note></para>
+
<section id="install">
<title>Installing JBoss Messaging on JBoss AS 4.2</title>
-
- <para>In this section we present two different methods of installing JBoss Messaging in JBoss AS 4.2
- </para>
-
+
+ <para>In this section we present two different methods of installing JBoss
+ Messaging in JBoss AS 4.2</para>
+
<itemizedlist>
-
- <listitem>If you have a completely clean JBoss AS 4.2.0 installation
- then you can do an <xref linkend="install.automated">automatic install</xref>.
- </listitem>
-
- <listitem>If you have a JBoss 4.2.0 that you have changed in some
- way from a clean JBoss AS 4.2.0 installation then you will need to do a
- <xref linkend="install.manual">manual install</xref>.
- </listitem>
-
+ <listitem>
+ If you have a completely clean JBoss AS 4.2.0 installation then you can do an
+
+ <xref linkend="install.automated">automatic install</xref>
+
+ .
+ </listitem>
+
+ <listitem>
+ If you have a JBoss 4.2.0 that you have changed in some way from a clean JBoss AS 4.2.0 installation then you will need to do a
+
+ <xref linkend="install.manual">manual install</xref>
+
+ .
+ </listitem>
</itemizedlist>
-
+
<section id="install.automated">
<title>Automated Installation</title>
-
- <para>
- <note>
- This procedure should only be performed from a clean JBoss AS 4.2 installation.
- If you have modifed the JBoss AS 4.2 installation at all since installation then you will need to
- perform a manual clustered JBoss Messaging installation
- </note>
- </para>
-
+
+ <para><note>
+ This procedure should only be performed from a clean JBoss AS 4.2 installation. If you have modifed the JBoss AS 4.2 installation at all since installation then you will need to perform a manual clustered JBoss Messaging installation
+ </note></para>
+
<itemizedlist>
+ <listitem>
+ <para>Set up the <literal>JBOSS_HOME</literal> environment variable
+ to point to the JBoss 4.2 installation you want to use JBoss
+ Messaging with.</para>
- <listitem>
- <para>Set up the <literal>JBOSS_HOME</literal> environment variable to
- point to the JBoss 4.2 installation you want to use JBoss Messaging
- with.</para>
-<para>
- Run the installation script, available in the
- <filename>util</filename> directory of the release bundle as follows:</para>
+ <para>Run the installation script, available in the
+ <filename>util</filename> directory of the release bundle as
+ follows:</para>
- <para>If you want to create a simple non clustered installion based on the default configuration:</para>
+ <para>If you want to create a simple non clustered installion based
+ on the default configuration:</para>
- <programlisting>
+ <programlisting>
cd util
ant -f release-admin.aml
</programlisting>
- <para>If you want to create a clustered installation based on the all configuration or change the configuration name:</para>
- <programlisting>
+
+ <para>If you want to create a clustered installation based on the
+ all configuration or change the configuration name:</para>
+
+ <programlisting>
cd util
ant -f release-admin.xml -Dmessaging.config.source=all -Dmessaging.config.name=messaging-node0
</programlisting>
-
- <para>In the above you would substitute <literal>messaging-node0</literal> with whatever is the
- name you want to give the configuration. If you will have several cluster nodes on the same machine, e.g.
- for development purposes then a good convention is to name them <literal>messaging-node0, messaging-node1</literal>
- to match <literal>messaging-node<ServerPeerID></literal></para>
- <para>The messaging.config.source variable determines which JBoss AS configuration (e.g. default or all) to base the installation on</para>
- <para>The installation script will create a
- <filename>$JBOSS_HOME/server/messaging-node0</filename> configuration. (If you have chosen <literal>messaging-node0</literal>)</para>
-
- </listitem>
+ <para>In the above you would substitute
+ <literal>messaging-node0</literal> with whatever is the name you
+ want to give the configuration. If you will have several cluster
+ nodes on the same machine, e.g. for development purposes then a good
+ convention is to name them <literal>messaging-node0,
+ messaging-node1</literal> to match
+ <literal>messaging-node<ServerPeerID></literal></para>
-
- <para>For the rest of the procedure we assume JBOSS_CONFIG refers to your new messaging configuration (e.g. messaging-node0 or messaging)
- </para>
-
- <para>You don't actually have to create an environment variable <literal>JBOSS_CONFIG</literal>, this is just
- used in the installation instructions to describe the steps</para>
-
- <listitem>
- <para><warning>For a clustered installation it is mandatory that a shared database is available to
- all nodes in the cluster.
- The default JBoss AS uses HSQLDB for its database which is a local shared database.
- Therefore in order to use clustering you must replace this with a different shared database.
- If the database is not replaced then clustering will not work.
- </warning></para>
+ <para>The messaging.config.source variable determines which JBoss AS
+ configuration (e.g. default or all) to base the installation
+ on</para>
+ <para>The installation script will create a
+ <filename>$JBOSS_HOME/server/messaging-node0</filename>
+ configuration. (If you have chosen
+ <literal>messaging-node0</literal>)</para>
+ </listitem>
+
+ <para>For the rest of the procedure we assume JBOSS_CONFIG refers to
+ your new messaging configuration (e.g. messaging-node0 or
+ messaging)</para>
+
+ <para>You don't actually have to create an environment variable
+ <literal>JBOSS_CONFIG</literal>, this is just used in the installation
+ instructions to describe the steps</para>
+
+ <listitem>
+ <para>
+ <warning>For a clustered installation it is mandatory that a
+ shared database is available to all nodes in the cluster. The
+ default JBoss AS uses HSQLDB for its database which is a local
+ shared database. Therefore in order to use clustering you must
+ replace this with a different shared database. If the database is
+ not replaced then clustering will not work.</warning>
+ </para>
+
<itemizedlist>
<listitem>
- <para>Replace
+ <para>Replace
<literal>$JBOSS_CONFIG/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml</literal>
- by the <literal>databasename>-persistence-service</literal> from
- <literal><downloadPackage>/examples/config.</literal>. For instance
- <literal>mysql-persistence-service.xml</literal>
- </para>
+ by the <literal>databasename>-persistence-service</literal>
+ from
+ <literal><downloadPackage>/examples/config.</literal>. For
+ instance <literal>mysql-persistence-service.xml</literal></para>
</listitem>
+ <listitem><para>Configure a JCA datasource using an example from
+ <literal>$JBOSS_HOME/docs/examples/jca</literal></para> and
+ copying to <literal>$JBOSS_CONFIG/deploy</literal> <para>JBoss
+ Messaging uses <literal>DefaultDS</literal> by default so you
+ should configure your datasource to bind to that</para></listitem>
+
<listitem>
- <para>Configure a JCA datasource using an example from
- <literal>$JBOSS_HOME/docs/examples/jca</literal></para> and copying to
- <literal>$JBOSS_CONFIG/deploy</literal>
- <para>JBoss Messaging uses <literal>DefaultDS</literal> by default so you should configure
- your datasource to bind to that</para>
+ <para>Remove hsqldb-ds.xml from
+ <literal>$JBOSS_CONFIG/deploy</literal></para>
</listitem>
<listitem>
- <para>Remove hsqldb-ds.xml from <literal>$JBOSS_CONFIG/deploy</literal></para>
+ <para>Copy your database driver to
+ <literal>$JBOSS_CONFIG/lib</literal></para>
+
+ <para>Your database driver can probably be downloaded from your
+ database provider's web site</para>
</listitem>
-
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
+ <para>Ensure the <literal>ServerPeerID</literal> MBean attribute
+ value in messaging-service.xml is unique for each node on the
+ cluster. The <literal>ServerPeerID</literal> value must be a valid
+ integer.</para>
+
+ <para>
+ <warning>Each node must have a unique
+ <literal>ServerPeerID</literal> for clustering to work!</warning>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>If you want to run multiple JBoss Messaging nodes on the same
+ box using the same IP address, e.g. for development purposes, then
+ you can use the ServiceBindingManager to do this as follows:</para>
+
+ <itemizedlist>
<listitem>
- <para>Copy your database driver to <literal>$JBOSS_CONFIG/lib</literal></para>
- <para>Your database driver can probably be downloaded from your database provider's
- web site</para>
- </listitem>
-
- </itemizedlist>
- </listitem>
-
- <listitem>
- <para>Ensure the <literal>ServerPeerID</literal> MBean attribute value in messaging-service.xml is unique for
- each node on the cluster. The <literal>ServerPeerID</literal> value must be a valid integer.</para>
- <para><warning>Each node must have a unique <literal>ServerPeerID</literal> for clustering to work!</warning></para>
- </listitem>
-
- <listitem>
- <para>If you want to run multiple JBoss Messaging nodes on the same box using the same IP address, e.g.
- for development purposes, then you can use the ServiceBindingManager to do this as follows:
- </para>
-
- <itemizedlist>
- <listitem>
<para>Uncomment binding manager service from
$JBOSS_CONFIG/conf/jboss-service.xml</para>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>Specify the desired port rage (e.g. ports-01, ports-02...
etc)</para>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>Look at
$JBOSS_HOME/docs/examples/binding-manager/sample-bindings.xml.
On each port range, JBoss Remoting configuration should look
@@ -215,73 +228,87 @@
</service-config>
</programlisting>
-
- <warning>You must ensure that the config (like above) is identical to that in <literal>remoting-bisocket-service.xml</literal>
- With the exception of the actual serverBindPort which clearly must be different for each ports range.
- Please note that the default JBoss Messaging service binding manager bindings in <literal>sample-bindings.xml</literal>
- shipped with JBAS 4.2.0 is out of date and you will need to copy the config from <literal>remoting-bisocket-service.xml</literal>
- </warning>
- <para>You should ensure that each node is configured to use a different ports range.</para>
+ <warning>You must ensure that the config (like above) is
+ identical to that in
+ <literal>remoting-bisocket-service.xml</literal> With the
+ exception of the actual serverBindPort which clearly must be
+ different for each ports range. Please note that the default
+ JBoss Messaging service binding manager bindings in
+ <literal>sample-bindings.xml</literal> shipped with JBAS 4.2.0
+ is out of date and you will need to copy the config from
+ <literal>remoting-bisocket-service.xml</literal></warning>
+
+ <para>You should ensure that each node is configured to use a
+ different ports range.</para>
</listitem>
</itemizedlist>
</listitem>
-
+
<listitem>
- <para>There are few extra steps at <xref
- linkend="install.extra-steps" /></para>
+ <para>There are few extra steps at <xref
+ linkend="install.extra-steps" /></para>
</listitem>
-
+
<listitem>That's it</listitem>
-
</itemizedlist>
-
</section>
-
-
-
- <section id="install.manual">
+
+ <section id="install.manual">
<title>Manual Installation</title>
-
- <para>
- <note>This installation procedure should be performed if you are installing into a JBoss AS
- configuration that you have changed in some way from the default JBoss AS distribution.
- If you are just using the standard, untouched JBoss AS 4.2 distribution you can use the automated procedure
- above
- </note>
- </para>
-
- <para>For this procedure we assume you already have your custom configuration located at
- <literal>JBOSS_CONFIG=$JBOSS_HOME/server/<myconfiguration></literal>, and that it contains a JBoss MQ
- installation.
- </para>
-
- <para>You don't actually have to create an environment variable <literal>JBOSS_CONFIG</literal>, this is just
- used in the installation instructions to describe the steps</para>
-
+
+ <para><note>
+ This installation procedure should be performed if you are installing into a JBoss AS configuration that you have changed in some way from the default JBoss AS distribution. If you are just using the standard, untouched JBoss AS 4.2 distribution you can use the automated procedure above
+ </note></para>
+
+ <para>For this procedure we assume you already have your custom
+ configuration located at
+ <literal>JBOSS_CONFIG=$JBOSS_HOME/server/<myconfiguration></literal>,
+ and that it contains a JBoss MQ installation.</para>
+
+ <para>You don't actually have to create an environment variable
+ <literal>JBOSS_CONFIG</literal>, this is just used in the installation
+ instructions to describe the steps</para>
+
<itemizedlist>
-
<listitem>
- <para>Move <literal>$JBOSS_CONFIG/deploy/jms/hajndi-jms-ds.xml</literal> and
- <literal>$JBOSS_CONFIG/deploy/jms/jms-ra.rar</literal> to <literal>$JBOSS_CONFIG/deploy</literal></para>
+ <para>Move
+ <literal>$JBOSS_CONFIG/deploy/jms/hajndi-jms-ds.xml</literal> and
+ <literal>$JBOSS_CONFIG/deploy/jms/jms-ra.rar</literal> to
+ <literal>$JBOSS_CONFIG/deploy</literal></para>
</listitem>
<listitem>
+
+
<para>Remove the old JBoss MQ by removing the directory
- <literal>$JBOSS_CONFIG/deploy/jms.</literal></para>.
-
- <para>Remove the old JBoss MQ jar file: <literal>$JBOSS_CONFIG/lib/jbossmq.jar</literal></para>
+ <literal>$JBOSS_CONFIG/deploy/jms.</literal></para>
- <para>Make sure you don't have any JBossMQ files under <literal>$JBOSS_CONFIG/deploy-hasingleton</literal>. For
- that just remove <literal>$JBOSS_CONFIG/deploy-hasingleton/jms</literal></para>
+ .
+
+ <para>Remove the old JBoss MQ jar file:
+ <literal>$JBOSS_CONFIG/lib/jbossmq.jar</literal></para>
+
+
+
+ <para>Make sure you don't have any JBossMQ files under
+ <literal>$JBOSS_CONFIG/deploy-hasingleton</literal>. For that just
+ remove
+ <literal>$JBOSS_CONFIG/deploy-hasingleton/jms</literal></para>
+
+
</listitem>
<listitem>
+
+
<para>Add a security policy called "messaging" on
$JBOSS_CONFIG/config/login-config.xml. You could use this as an
example, or create one according to JBoss Security
Documentation:</para>
+
+
<programlisting>
<application-policy name = "messaging">
<authentication>
@@ -294,14 +321,26 @@
</application-policy>
</programlisting>
- <para>In case you are using the above policy you should also create files
- <literal>messaging-users.properties</literal> and <literal>messaging-roles.properties</literal> in the
- <literal>$JBOSS_CONFIG/config/props/</literal> directory</para>.
-
- <para><note>You can find an example <literal>messaging-users.properties</literal> and
- <literal>messaging-roles.properties</literal> in the JBoss Messaging distribution in the
- <literal><downloadPackage>src/etc/server/default/config</literal> directory.</note></para>
+
+ <para>In case you are using the above policy you should also create
+ files <literal>messaging-users.properties</literal> and
+ <literal>messaging-roles.properties</literal> in the
+ <literal>$JBOSS_CONFIG/config/props/</literal> directory</para>
+
+ .
+
+ <para>
+ <note>You can find an example
+ <literal>messaging-users.properties</literal> and
+ <literal>messaging-roles.properties</literal> in the JBoss
+ Messaging distribution in the
+ <literal><downloadPackage>src/etc/server/default/config</literal>
+ directory.</note>
+ </para>
+
+
+
<programlisting>
# messaging-roles.properties
# Add roles as you like
@@ -310,6 +349,8 @@
guest=guest
</programlisting>
+
+
<programlisting>
# messaging-users.properties
@@ -318,84 +359,109 @@
#
guest=guest
</programlisting>
+
+
</listitem>
<listitem>
- <para>Unzip jboss-messaging.sar from your download package into the directory
+ <para>Unzip jboss-messaging.sar from your download package into the
+ directory
<literal>JBOSS_CONFIG/deploy/jboss-messaging.sar</literal></para>
- <para>JBoss Messaging should be deployed unzipped (exploded) so you have easy access to its config
- files which are stored there.</para>
+
+ <para>JBoss Messaging should be deployed unzipped (exploded) so you
+ have easy access to its config files which are stored there.</para>
</listitem>
<listitem>
- <para>Copy jboss-messaging.jar from your download package into the directory
- <literal>JBOSS_CONFIG/lib</literal></para>
- <para>jboss-messaging.jar needs to go in the lib directory so it is accessible to other services e.g.
-the JBoss Transactions Recovery Manager</para>
+ <para>Copy jboss-messaging.jar from your download package into the
+ directory <literal>JBOSS_CONFIG/lib</literal></para>
+
+ <para>jboss-messaging.jar needs to go in the lib directory so it is
+ accessible to other services e.g. the JBoss Transactions Recovery
+ Manager</para>
</listitem>
- <listitem>
- <para><warning>For a clustered installation it is mandatory that a shared database is available to
- all nodes in the cluster.
- The default JBoss AS uses HSQLDB for its database which is a local shared database.
- Therefore in order to use clustering you must replace this with a different shared database.
- If the database is not replaced then clustering will not work.
- </warning></para>
+ <listitem>
+ <para><warning>
+ For a clustered installation it is mandatory that a shared database is available to all nodes in the cluster. The default JBoss AS uses HSQLDB for its database which is a local shared database. Therefore in order to use clustering you must replace this with a different shared database. If the database is not replaced then clustering will not work.
+ </warning></para>
<itemizedlist>
<listitem>
- <para>Replace
+ <para>Replace
<literal>$JBOSS_CONFIG/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml</literal>
- by the <literal>databasename>-persistence-service</literal> from
- <literal><downloadPackage>/examples/config.</literal>. For instance
- <literal>mysql-persistence-service.xml</literal>
- </para>
+ by the <literal>databasename>-persistence-service</literal>
+ from
+ <literal><downloadPackage>/examples/config.</literal>. For
+ instance <literal>mysql-persistence-service.xml</literal></para>
</listitem>
<listitem>
+
+
<para>Configure a JCA datasource using an example from
- <literal>$JBOSS_HOME/docs/examples/jca</literal></para> and copying to
+ <literal>$JBOSS_HOME/docs/examples/jca</literal></para>
+
+ and copying to
+
<literal>$JBOSS_CONFIG/deploy</literal>
- <para>JBoss Messaging uses <literal>DefaultDS</literal> by default so you should configure
- your datasource to bind to that</para>
+
+
+
+ <para>JBoss Messaging uses <literal>DefaultDS</literal> by
+ default so you should configure your datasource to bind to
+ that</para>
+
+
</listitem>
<listitem>
- <para>Remove hsqldb-ds.xml from <literal>$JBOSS_CONFIG/deploy</literal></para>
+ <para>Remove hsqldb-ds.xml from
+ <literal>$JBOSS_CONFIG/deploy</literal></para>
</listitem>
-
+
<listitem>
- <para>Copy your database driver to <literal>$JBOSS_CONFIG/lib</literal></para>
- <para>Your database driver can probably be downloaded from your database provider's
- web site</para>
+ <para>Copy your database driver to
+ <literal>$JBOSS_CONFIG/lib</literal></para>
+
+ <para>Your database driver can probably be downloaded from your
+ database provider's web site</para>
</listitem>
-
</itemizedlist>
- </listitem>
-
- <listitem>
- <para>Ensure the <literal>ServerPeerID</literal> MBean attribute value in messaging-service.xml is unique for
- each node on the cluster. The <literal>ServerPeerID</literal> value must be a valid integer.</para>
- <para><warning>Each node must have a unique <literal>ServerPeerID</literal> for clustering to work!</warning></para>
- </listitem>
-
- <listitem>
- <para>If you want to run multiple JBoss Messaging nodes on the same box using the same IP address, e.g.
- for development purposes, then you can use the ServiceBindingManager to do this as follows:
- </para>
-
- <itemizedlist>
- <listitem>
+ </listitem>
+
+ <listitem>
+ <para>Ensure the <literal>ServerPeerID</literal> MBean attribute
+ value in messaging-service.xml is unique for each node on the
+ cluster. The <literal>ServerPeerID</literal> value must be a valid
+ integer.</para>
+
+ <para><warning>
+ Each node must have a unique
+
+ <literal>ServerPeerID</literal>
+
+ for clustering to work!
+ </warning></para>
+ </listitem>
+
+ <listitem>
+ <para>If you want to run multiple JBoss Messaging nodes on the same
+ box using the same IP address, e.g. for development purposes, then
+ you can use the ServiceBindingManager to do this as follows:</para>
+
+ <itemizedlist>
+ <listitem>
<para>Uncomment binding manager service from
$JBOSS_CONFIG/conf/jboss-service.xml</para>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>Specify the desired port rage (e.g. ports-01, ports-02...
etc)</para>
- </listitem>
+ </listitem>
- <listitem>
+ <listitem>
<para>Look at
$JBOSS_HOME/docs/examples/binding-manager/sample-bindings.xml.
On each port range, JBoss Remoting configuration should look
@@ -442,69 +508,94 @@
</service-config>
</programlisting>
-
- <warning>You must ensure that the config (like above) is identical to that in <literal>remoting-bisocket-service.xml</literal>
- With the exception of the actual serverBindPort which clearly must be different for each ports range.
- Please note that the default JBoss Messaging service binding manager bindings in <literal>sample-bindings.xml</literal>
- shipped with JBAS 4.2.0 is out of date and you will need to copy the config from <literal>remoting-bisocket-service.xml</literal>
+
+ <warning>
+ You must ensure that the config (like above) is identical to that in
+
+ <literal>remoting-bisocket-service.xml</literal>
+
+ With the exception of the actual serverBindPort which clearly must be different for each ports range. Please note that the default JBoss Messaging service binding manager bindings in
+
+ <literal>sample-bindings.xml</literal>
+
+ shipped with JBAS 4.2.0 is out of date and you will need to copy the config from
+
+ <literal>remoting-bisocket-service.xml</literal>
+
+
</warning>
- <para>You should ensure that each node is configured to use a different ports range.</para>
+ <para>You should ensure that each node is configured to use a
+ different ports range.</para>
</listitem>
</itemizedlist>
</listitem>
-
+
<listitem>
- <para>There are few extra steps at <xref
- linkend="install.extra-steps" /></para>
+ <para>There are few extra steps at <xref
+ linkend="install.extra-steps" /></para>
</listitem>
-
- <listitem>That's it</listitem>
-
+
+ <listitem>
+ That's it
+ </listitem>
</itemizedlist>
-
- </section>
+ </section>
<section id="install.extra-steps">
<title>Extra steps to complete your installation</title>
<itemizedlist>
-
<listitem>
- <para>
- <warning>SECURITY RISK! To avoid a security risk, you MUST specify the value of the attribute SuckerPassword in the Server Peer config (messaging-service.xml). If you do not specify a value, the default value will be used. Any person
-that knows the default value will be able to access to all destinations on the server. The password chosen
-should only be exposed to administrators</warning>
- </para>
+ <para>
+ <warning>SECURITY RISK! To avoid a security risk, you MUST specify
+ the value of the attribute SuckerPassword in the Server Peer
+ config (messaging-service.xml). If you do not specify a value, the
+ default value will be used. Any person that knows the default
+ value will be able to access to all destinations on the server.
+ The password chosen should only be exposed to
+ administrators</warning>
+ </para>
</listitem>
- <listitem>
+ <listitem>
<para>
- <note>JBoss Messaging 1.4.0 requires a patched version of jboss-remoting.jar. This version is not available
- in the JBoss AS 4.2.0 or JBoss AS 4.2.1 distributions. The patched jar can be found <ulink url="http://repository.jboss.com/jboss/remoting/2.2.2.SP1-brew/lib/">here</ulink>. Please download it and copy it into the <literal>$JBOSS_HOME/server/<your server name>/lib directory</literal> of any server profiles that use JBoss Messaging 1.4.0. If you are using JBoss Messaging from a standalone client also make sure this jar is on your classpath *before* jbossall-client.jar.</note>
+ <note>JBoss Messaging 1.4.0 requires a patched version of
+ jboss-remoting.jar. This version is not available in the JBoss AS
+ 4.2.0 or JBoss AS 4.2.1 distributions. The patched jar can be
+ found <ulink
+ url="http://repository.jboss.com/jboss/remoting/2.2.2.SP1-brew/lib/">here</ulink>.
+ Please download it and copy it into the
+ <literal>$JBOSS_HOME/server/<your server name>/lib
+ directory</literal> of any server profiles that use JBoss
+ Messaging 1.4.0. If you are using JBoss Messaging from a
+ standalone client also make sure this jar is on your classpath
+ *before* jbossall-client.jar.</note>
</para>
- </listitem>
+ </listitem>
+ <para>You should also make these changes on any configuration you
+ choose, to remove all references to the old JBossMQ:</para>
- <para>You should also make these changes on any configuration you
- choose, to remove all references to the old JBossMQ:</para>
+ <listitem>
+ <para>Edit <literal>$JBOSS_CONFIG/deploy/jms-ds.xml</literal> and
+ replace jboss.mq by jboss.messaging on every occurrence</para>
+ <para>If you are in a clustered installation, then do the above with
+ the file
+ <literal>$JBOSS_CONFIG/deploy/hajndi-jms-ds.xml</literal></para>
+ </listitem>
<listitem>
- <para>Edit <literal>$JBOSS_CONFIG/deploy/jms-ds.xml</literal> and replace
- jboss.mq by jboss.messaging on every occurrence</para>
- <para>If you are in a clustered installation, then do the above with the file
- <literal>$JBOSS_CONFIG/deploy/hajndi-jms-ds.xml</literal>
- </para>
- </listitem>
-
- <listitem>
<para>Edit <literal>$JBOSS_CONFIG/conf/standardjboss.xml</literal>
- and set <literal>CreateJBossMQDestination</literal> to false on every occurrence</para>
+ and set <literal>CreateJBossMQDestination</literal> to false on
+ every occurrence</para>
<para>Make sure it looks like this:</para>
- <para><literal><CreateJBossMQDestination>false</CreateJBossMQDestination></literal></para>
+ <para>
+ <literal><CreateJBossMQDestination>false</CreateJBossMQDestination></literal>
+ </para>
<para>Those Proxies will try to create a Destination on JBossMQ if
they can't find it on JNDI, what would cause some errors related to
@@ -512,9 +603,8 @@
</listitem>
<listitem>
- <para>Edit $JBOSS_CONFIG/conf/jboss-service.xml
- and remove the reference to JBoss MQ on JSR-77 Management
- Bean:</para>
+ <para>Edit $JBOSS_CONFIG/conf/jboss-service.xml and remove the
+ reference to JBoss MQ on JSR-77 Management Bean:</para>
<programlisting>
<!-- ==================================================================== -->
@@ -567,26 +657,24 @@
</section>
</section>
-
<section id="startingtheservice">
<title>Starting the Server</title>
<para>To run the server, execute the <filename>run.bat</filename> or
<filename>run.sh</filename> script as appropriate for your operating
system, in the <filename>$JBOSS_HOME/bin</filename> directory.</para>
-
+
<programlisting>
cd $JBOSS_HOME/bin
./run.sh -c <config name>
</programlisting>
-
- <para>Where config_name is the name of the JBoss AS configuration where you have installed messaging.
- (The default is 'messaging')
- </para>
+ <para>Where config_name is the name of the JBoss AS configuration where
+ you have installed messaging. (The default is 'messaging')</para>
+
<para>A successful JBoss Messaging deployment generates logging output
- similar to for a non clustered installation (for a clustered installation you will also see extra
- cluster related output)</para>
+ similar to for a non clustered installation (for a clustered installation
+ you will also see extra cluster related output)</para>
<programlisting>
....
@@ -707,9 +795,10 @@
bundle and drill down to <filename>/examples/queue</filename>. Apache Ant
must pe present in your path in order to be able to run the
example.</para>
-
- <para>Make sure you start the JBoss server before trying to run the tests</para>
+ <para>Make sure you start the JBoss server before trying to run the
+ tests</para>
+
<programlisting>
setenv JBOSS_HOME=<your_JBoss_installation>
@@ -768,68 +857,69 @@
linkend="examples" />, we will have a look at each of those
examples.</para>
</section>
-
+
<section id="inst.remoteclient">
<title>Accessing JBoss Messaging from a remote client</title>
-
- <para>
- In order to access JBoss Messaging from a client outside the JBoss app server, you will need to ensure the
- following jar files are on the client classpath:
- </para>
-
+
+ <para>In order to access JBoss Messaging from a client outside the JBoss
+ app server, you will need to ensure the following jar files are on the
+ client classpath:</para>
+
<itemizedlist>
- <listitem>
- <para>
- <note>JBoss Messaging 1.4.0 requires a patched version of jboss-remoting.jar. This version is not available
- in the JBoss AS 4.2.0 or JBoss AS 4.2.1 distributions. The patched jar can be found <ulink url="http://repository.jboss.com/jboss/remoting/2.2.2.SP1-brew/lib/">here</ulink>. Please download it and make sure this jar is on your classpath *before* jbossall-client.jar.</note>
- </para>
- </listitem>
- <listitem>
- <para>
- jboss-messaging-client.jar - This is available in the messaging distribution
- </para>
- </listitem>
- <listitem>
- <para>
- jbossall-client.jar - This is available in your $JBOSS_HOME/client directory
- </para>
- </listitem>
- <listitem>
- <para>$JBOSS_HOME/server/<SERVER_NAME>/deploy/jboss-aop.deployer/jboss-aop.jar</para>
+ <listitem>
+ <para><note>
+ JBoss Messaging 1.4.0 requires a patched version of jboss-remoting.jar. This version is not available in the JBoss AS 4.2.0 or JBoss AS 4.2.1 distributions. The patched jar can be found
- <para>JBoss AOP 1.5.5.GA+</para>
+ <ulink
+ url="http://repository.jboss.com/jboss/remoting/2.2.2.SP1-brew/lib/">here</ulink>
- <para><ulink
- url="http://repository.jboss.com/jboss/aop/1.5.5.GA/lib/">http://repository.jboss.com/jboss/aop/1.5.5.GA/lib/</ulink></para>
+ . Please download it and make sure this jar is on your classpath *before* jbossall-client.jar.
+ </note></para>
+ </listitem>
- <para>(For AOP, sometimes you have to use a specific JAR according
- to your JVM of choice. Use the most convenient for you)</para>
- </listitem>
-
- <listitem>
- <para>$JBOSS_HOME/server/<SERVER_NAME>/lib/javassist.jar</para>
+ <listitem>
+ <para>jboss-messaging-client.jar - This is available in the messaging
+ distribution</para>
+ </listitem>
- <para>Javassist 3.5.0.GA-brew+</para>
+ <listitem>
+ <para>jbossall-client.jar - This is available in your
+ $JBOSS_HOME/client directory</para>
+ </listitem>
- <para><ulink
- url="http://repository.jboss.com/javassist/3.5.0.GA-brew/lib/">http://repository.jboss.com/javassist/3.5.0.GA-brew/lib/</ulink></para>
- </listitem>
-
- <listitem>
-
- <para>$JBOSS_HOME/server/<SERVER_NAME>/lib/trove.jar</para>
-
- <para>trove 1.0.2-brew</para>
-
- <para><ulink
- url="http://repository.jboss.com/trove/1.0.2-brew/lib/">http://repository.jboss.com/trove/1.0.2-brew/lib/</ulink></para>
+ <listitem>
+ <para>$JBOSS_HOME/server/<SERVER_NAME>/deploy/jboss-aop.deployer/jboss-aop.jar</para>
- </listitem>
-
- <listitem>
- <para>log4j</para>
- </listitem>
-
+ <para>JBoss AOP 1.5.5.GA+</para>
+
+ <para><ulink
+ url="http://repository.jboss.com/jboss/aop/1.5.5.GA/lib/">http://repository.jboss.com/jboss/aop/1.5.5.GA/lib/</ulink></para>
+
+ <para>(For AOP, sometimes you have to use a specific JAR according to
+ your JVM of choice. Use the most convenient for you)</para>
+ </listitem>
+
+ <listitem>
+ <para>$JBOSS_HOME/server/<SERVER_NAME>/lib/javassist.jar</para>
+
+ <para>Javassist 3.5.0.GA-brew+</para>
+
+ <para><ulink
+ url="http://repository.jboss.com/javassist/3.5.0.GA-brew/lib/">http://repository.jboss.com/javassist/3.5.0.GA-brew/lib/</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para>$JBOSS_HOME/server/<SERVER_NAME>/lib/trove.jar</para>
+
+ <para>trove 1.0.2-brew</para>
+
+ <para><ulink
+ url="http://repository.jboss.com/trove/1.0.2-brew/lib/">http://repository.jboss.com/trove/1.0.2-brew/lib/</ulink></para>
+ </listitem>
+
+ <listitem>
+ <para>log4j</para>
+ </listitem>
</itemizedlist>
</section>
-</chapter>
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/introduction.xml
===================================================================
--- trunk/docs/userguide/en/modules/introduction.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/introduction.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -1,236 +1,204 @@
+<?xml version="1.0" encoding="UTF-8"?>
<chapter id="introduction">
+ <title>Introduction</title>
- <title>Introduction</title>
+ <para>JBoss Messaging provides an open source and standards-based messaging
+ platform that brings enterprise-class messaging to the mass market.</para>
- <para>
- JBoss Messaging provides an open source and standards-based messaging platform that brings
- enterprise-class messaging to the mass market.
- </para>
+ <para>JBoss Messaging implements a high performance, robust messaging core
+ that is designed to support the largest and most heavily utilized SOAs,
+ enterprise service buses (ESBs) and other integration needs ranging from the
+ simplest to the highest demand networks.</para>
- <para>
- JBoss Messaging implements a high performance, robust messaging core that is designed to
- support the largest and most heavily utilized SOAs, enterprise service buses (ESBs) and other
- integration needs ranging from the simplest to the highest demand networks.
- </para>
- <para>
- It will allow you to smoothly distribute your application load across your cluster,
- intelligently balancing and utilizing each nodes CPU cycles, with no single point of failure,
- providing a highly scalable and perform-ant clustering implementation.
- </para>
- <para>
- JBoss Messaging includes
- a JMS front-end to deliver messaging in a standards-based format as well as being designed to be
- able to support other messaging protocols in the future.
- </para>
+ <para>It will allow you to smoothly distribute your application load across
+ your cluster, intelligently balancing and utilizing each nodes CPU cycles,
+ with no single point of failure, providing a highly scalable and perform-ant
+ clustering implementation.</para>
- <para>
- JBoss Messaging is destined to become an integral part of the JBoss Enterprise Application Platform,
- and the new Service Integration Platform.
- </para>
- <para>
- Currently it is available for embedded use within the JBoss Application Server
- 4.2.0.GA or later (JBossAS). Work to integrate JBoss Messaging with the new JBoss Microcontainer is under way.
- </para>
-
- <para>
- JBoss Messaging is also an integral part of Red Hat's strategy for messaging.
- JBoss Messaging is fully committed to AMQP ( <ulink url="http://www.amqp.org">AMQP</ulink>)- the new messaging standard from Red Hat
- and others. Later versions of JBoss Messaging will support AMQP, and JBoss Messaging will be focussed
- on becoming the premier AMQP Java broker.
- </para>
+ <para>JBoss Messaging includes a JMS front-end to deliver messaging in a
+ standards-based format as well as being designed to be able to support other
+ messaging protocols in the future.</para>
- <section id="support">
- <title>JBoss Messaging support cover from Red Hat</title>
+ <para>JBoss Messaging is destined to become an integral part of the JBoss
+ Enterprise Application Platform, and the new Service Integration
+ Platform.</para>
- <para>
- JBoss Messaging is destained to become part of both Application Server Platform (JBoss 4.2
- series) and Service Integration Platform (JBoss ESB 4 series) as default JMS provider.
- Production support will then be fully available for these plaforms and it will cover JBoss
- Messaging.
- </para>
- <para>
- Currently developer support is available for JBoss Messaging when installed in JBoss 4.2.x
- </para>
+ <para>Currently it is available for embedded use within the JBoss
+ Application Server 4.2.0.GA or later (JBossAS). Work to integrate JBoss
+ Messaging with the new JBoss Microcontainer is under way.</para>
+ <para>JBoss Messaging is also an integral part of Red Hat's strategy for
+ messaging. JBoss Messaging is fully committed to AMQP ( <ulink
+ url="http://www.amqp.org">AMQP</ulink>)- the new messaging standard from Red
+ Hat and others. Later versions of JBoss Messaging will support AMQP, and
+ JBoss Messaging will be focussed on becoming the premier AMQP Java
+ broker.</para>
- </section>
+ <section id="support">
+ <title>JBoss Messaging support cover from Red Hat</title>
- <section id="features">
- <title>JBoss Messaging Features</title>
+ <para>JBoss Messaging is destained to become part of both Application
+ Server Platform (JBoss 4.2 series) and Service Integration Platform (JBoss
+ ESB 4 series) as default JMS provider. Production support will then be
+ fully available for these plaforms and it will cover JBoss
+ Messaging.</para>
- <para>
- JBoss Messaging provides:
- </para>
+ <para>Currently developer support is available for JBoss Messaging when
+ installed in JBoss 4.2.x</para>
+ </section>
- <itemizedlist>
- <listitem>
- <para>
- A fully compatible and Sun certified JMS 1.1 implementation, that currently works
- with a standard 4.2.x JBoss Application Server installation.
- </para>
- </listitem>
- <listitem>
- <para>
- A strong focus on performance, reliability and scalability with high throughput and
- low latency.
- </para>
- </listitem>
- <listitem>
- <para>
- A foundation for JBoss ESB for SOA initiatives; JBoss ESB uses
- JBoss Messaging as its default JMS provider.
- </para>
- </listitem>
- </itemizedlist>
+ <section id="features">
+ <title>JBoss Messaging Features</title>
- <para>
- Other JBoss Messaging features include:
- </para>
+ <para>JBoss Messaging provides:</para>
- <itemizedlist>
- <listitem>
- <para>
- Publish-subscribe and point-to-point messaging models
- </para>
- </listitem>
- <listitem>
- <para>
- Persistent and non-persistent messages
- </para>
- </listitem>
- <listitem>
- <para>
- Guaranteed message delivery that ensures that messages arrive once and only once where required
- </para>
- </listitem>
- <listitem>
- <para>
- Transactional and reliable - supporting ACID semantics
- </para>
- </listitem>
- <listitem>
- <para>
- Customizable security framework based on JAAS
- </para>
- </listitem>
- <listitem>
- <para>
- Fully integrated with JBoss Transactions (formerly known as Arjuna JTA) for full transaction recoverability.
- </para>
- </listitem>
- <listitem>
- <para>
- Extensive JMX management interface
- </para>
- </listitem>
- <listitem>
- <para>
- Support for most major databases including Oracle, Sybase, MS SQL Server, PostgreSQL and MySQL
- </para>
- </listitem>
- <listitem>
- <para>
- HTTP transport
- </para>
- </listitem>
- <listitem>
- <para>
- SSL transport
- </para>
- </listitem>
- </itemizedlist>
+ <itemizedlist>
+ <listitem>
+ <para>A fully compatible and Sun certified JMS 1.1 implementation,
+ that currently works with a standard 4.2.x JBoss Application Server
+ installation.</para>
+ </listitem>
- <para>
- Clustering features:
- </para>
+ <listitem>
+ <para>A strong focus on performance, reliability and scalability with
+ high throughput and low latency.</para>
+ </listitem>
- <itemizedlist>
- <listitem>
- <para>
- Distributed queues. Messages sent to a distributed queue while attached to a
- particular node will be routed to a queue instance on a particular node according
- to a routing policy.
- </para>
- </listitem>
- <listitem>
- <para>
- Distributed topics. Messages sent to a distributed topic while attached at a
- particular node will be received by subscriptions on other nodes.
- </para>
- </listitem>
- <listitem>
- <para>
- Fully reliable message distribution. Once and only once delivery is fully guaranteed.
- When sending messages to a topic with multiple durable subscriptions
- across a cluster we guarantee that message reaches all the subscriptions
- (or none of them in case of failure).
- </para>
- </listitem>
- <listitem>
- <para>
- Pluggable routing implementation. The policy for routing messages to a queue is fully
- pluggable and easily replaceable. The default policy always chooses a queue at the local
- node if there is one, and if not, it round robins between queues on different nodes.
- </para>
- </listitem>
- <listitem>
- <para>
- Intelligent message redistribution policy. Messages are automatically distributed between
- nodes depending on how fast or slow consumers are on certain nodes. If there are no or slow
- consumers on a particular queue node, messages will be pulled from that queue to a queue with
- faster consumers on a different node. The policy is fully pluggable.
- </para>
- </listitem>
- <listitem>
- <para>
- Shared durable subscriptions. Consumers can connect to the same durable subscription while
- attached to different nodes. This allows processing load from durable subscriptions to be
- distributed across the cluster in a similar way to queues.
- </para>
- </listitem>
- <listitem>
- <para>
- High availability and seamless fail-over. If the node you are connected to fails, you
- will automatically fail over to another node and will not lose any persistent messages.
- You can carry on with your session seamlessly where you left off. Once and only once
- delivery of persistent messages is respected at all times.
- </para>
- </listitem>
- <listitem>
- <para>
- Message bridge. JBoss Messaging contains a message bridge component which enables you to bridge messages between any two JMS1.1 destinations
- on the same or physical separate locations. (E.g. separated by a WAN)
- </para>
- </listitem>
- </itemizedlist>
+ <listitem>
+ <para>A foundation for JBoss ESB for SOA initiatives; JBoss ESB uses
+ JBoss Messaging as its default JMS provider.</para>
+ </listitem>
+ </itemizedlist>
+ <para>Other JBoss Messaging features include:</para>
- </section>
+ <itemizedlist>
+ <listitem>
+ <para>Publish-subscribe and point-to-point messaging models</para>
+ </listitem>
+ <listitem>
+ <para>Persistent and non-persistent messages</para>
+ </listitem>
- <section id="compatibility">
- <title>Compatibility with JBossMQ</title>
+ <listitem>
+ <para>Guaranteed message delivery that ensures that messages arrive
+ once and only once where required</para>
+ </listitem>
- <para>
- JBoss MQ is the JMS implementation currently shipped within JBoss AS.
- Since JBoss Messaging is JMS 1.1 and JMS 1.0.2b compatible, the JMS code written against
- JBossMQ will run with JBoss Messaging without any changes.
- </para>
-
- <para>
- JBoss Messaging does not have wire format compatibility with JBoss MQ so it would be necessary to upgrade
- JBoss MQ clients with JBoss Messaging client jars
- </para>
+ <listitem>
+ <para>Transactional and reliable - supporting ACID semantics</para>
+ </listitem>
- <important>
- Even if JBoss Messaging deployment descriptors are very similar to JBoss MQ
- deployment descriptors, they are <emphasis>not</emphasis> identical, so they will require
- some simple adjustments to get them to work with JBoss Messaging. Also, the database
- data model is completely different, so don't attempt to use JBoss Messaging with a JBoss MQ
- data schema and vice-versa.
- </important>
-
- </section>
-
+ <listitem>
+ <para>Customizable security framework based on JAAS</para>
+ </listitem>
-</chapter>
+ <listitem>
+ <para>Fully integrated with JBoss Transactions (formerly known as
+ Arjuna JTA) for full transaction recoverability.</para>
+ </listitem>
+
+ <listitem>
+ <para>Extensive JMX management interface</para>
+ </listitem>
+
+ <listitem>
+ <para>Support for most major databases including Oracle, Sybase, MS
+ SQL Server, PostgreSQL and MySQL</para>
+ </listitem>
+
+ <listitem>
+ <para>HTTP transport</para>
+ </listitem>
+
+ <listitem>
+ <para>SSL transport</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Clustering features:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Distributed queues. Messages sent to a distributed queue while
+ attached to a particular node will be routed to a queue instance on a
+ particular node according to a routing policy.</para>
+ </listitem>
+
+ <listitem>
+ <para>Distributed topics. Messages sent to a distributed topic while
+ attached at a particular node will be received by subscriptions on
+ other nodes.</para>
+ </listitem>
+
+ <listitem>
+ <para>Fully reliable message distribution. Once and only once delivery
+ is fully guaranteed. When sending messages to a topic with multiple
+ durable subscriptions across a cluster we guarantee that message
+ reaches all the subscriptions (or none of them in case of
+ failure).</para>
+ </listitem>
+
+ <listitem>
+ <para>Pluggable routing implementation. The policy for routing
+ messages to a queue is fully pluggable and easily replaceable. The
+ default policy always chooses a queue at the local node if there is
+ one, and if not, it round robins between queues on different
+ nodes.</para>
+ </listitem>
+
+ <listitem>
+ <para>Intelligent message redistribution policy. Messages are
+ automatically distributed between nodes depending on how fast or slow
+ consumers are on certain nodes. If there are no or slow consumers on a
+ particular queue node, messages will be pulled from that queue to a
+ queue with faster consumers on a different node. The policy is fully
+ pluggable.</para>
+ </listitem>
+
+ <listitem>
+ <para>Shared durable subscriptions. Consumers can connect to the same
+ durable subscription while attached to different nodes. This allows
+ processing load from durable subscriptions to be distributed across
+ the cluster in a similar way to queues.</para>
+ </listitem>
+
+ <listitem>
+ <para>High availability and seamless fail-over. If the node you are
+ connected to fails, you will automatically fail over to another node
+ and will not lose any persistent messages. You can carry on with your
+ session seamlessly where you left off. Once and only once delivery of
+ persistent messages is respected at all times.</para>
+ </listitem>
+
+ <listitem>
+ <para>Message bridge. JBoss Messaging contains a message bridge
+ component which enables you to bridge messages between any two JMS1.1
+ destinations on the same or physical separate locations. (E.g.
+ separated by a WAN)</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section id="compatibility">
+ <title>Compatibility with JBossMQ</title>
+
+ <para>JBoss MQ is the JMS implementation currently shipped within JBoss
+ AS. Since JBoss Messaging is JMS 1.1 and JMS 1.0.2b compatible, the JMS
+ code written against JBossMQ will run with JBoss Messaging without any
+ changes.</para>
+
+ <para>JBoss Messaging does not have wire format compatibility with JBoss
+ MQ so it would be necessary to upgrade JBoss MQ clients with JBoss
+ Messaging client jars</para>
+
+ <important>
+ Even if JBoss Messaging deployment descriptors are very similar to JBoss MQ deployment descriptors, they are
+
+ <emphasis>not</emphasis>
+
+ identical, so they will require some simple adjustments to get them to work with JBoss Messaging. Also, the database data model is completely different, so don't attempt to use JBoss Messaging with a JBoss MQ data schema and vice-versa.
+ </important>
+ </section>
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/recovery_config.xml
===================================================================
--- trunk/docs/userguide/en/modules/recovery_config.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/recovery_config.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -2,18 +2,20 @@
<chapter id="recovery">
<title>JBoss Messaging XA Recovery Configuration</title>
- <para>This section describes how to configure JBoss Transactions in JBoss AS 4.2.0 to handle XA recovery for JBoss Messaging
- resources.
- </para>
-
- <para>JBoss Transactions recovery manager can easily be configured to continually poll for and recover JBoss Messaging XA resources,
- this provides an extremely high level of durability of transactions.
- </para>
+ <para>This section describes how to configure JBoss Transactions in JBoss AS
+ 4.2.0 to handle XA recovery for JBoss Messaging resources.</para>
- <para>Enabling JBoss Transactions Recovery Manager to recover JBoss Messaging resources is a very simple matter and involves adding a line to the file ${JBOSS_CONFIG}/conf/jbossjta-properties.xml</para>
+ <para>JBoss Transactions recovery manager can easily be configured to
+ continually poll for and recover JBoss Messaging XA resources, this provides
+ an extremely high level of durability of transactions.</para>
- <para>Here's an example section of a jbossjta-properties.xml file with the line added (note the whole file is not shown)</para>
+ <para>Enabling JBoss Transactions Recovery Manager to recover JBoss
+ Messaging resources is a very simple matter and involves adding a line to
+ the file ${JBOSS_CONFIG}/conf/jbossjta-properties.xml</para>
+ <para>Here's an example section of a jbossjta-properties.xml file with the
+ line added (note the whole file is not shown)</para>
+
<programlisting>
<properties depends="arjuna" name="jta">
<!--
@@ -41,20 +43,27 @@
</properties>
</programlisting>
-
- <para>In the above example the recovery manager will attempt to recover JMS resources using the JMSProviderLoader "DefaultJMSProvider"</para>
- <para>DefaultJMSProvider is the default JMS provider loader that ships with JBoss AS and is defined in jms-ds.xml (or hajndi-jms-ds.xml in
- a clustered configuration). If you want to recovery using a different JMS provider loader - e.g. one corresponding to a remote JMS provider
- then just add another line and instead of DefaultJMSProvider specify the name of the remote JMS provider as specified in it's MBean configuration.
- </para>
- <para>For each line you add, the name must be unique, so you could specify "com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1",
- "com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING2, ..." etc.</para>
- <para>In actual fact, the recovery also should work with any JMS provider that implements recoverable XAResources (i.e. it properly implements XAResource.recover())
- , not just JBoss Messaging</para>
- <para>Please note that to configure the recovery manager to recovery transactions from any node of the cluster it will be necessary to specify a line in the configuration for every node of the cluster
- </para>
-
-
+ <para>In the above example the recovery manager will attempt to recover JMS
+ resources using the JMSProviderLoader "DefaultJMSProvider"</para>
-</chapter>
+ <para>DefaultJMSProvider is the default JMS provider loader that ships with
+ JBoss AS and is defined in jms-ds.xml (or hajndi-jms-ds.xml in a clustered
+ configuration). If you want to recovery using a different JMS provider
+ loader - e.g. one corresponding to a remote JMS provider then just add
+ another line and instead of DefaultJMSProvider specify the name of the
+ remote JMS provider as specified in it's MBean configuration.</para>
+
+ <para>For each line you add, the name must be unique, so you could specify
+ "com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING1",
+ "com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING2, ..."
+ etc.</para>
+
+ <para>In actual fact, the recovery also should work with any JMS provider
+ that implements recoverable XAResources (i.e. it properly implements
+ XAResource.recover()) , not just JBoss Messaging</para>
+
+ <para>Please note that to configure the recovery manager to recovery
+ transactions from any node of the cluster it will be necessary to specify a
+ line in the configuration for every node of the cluster</para>
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/runningexamples.xml
===================================================================
--- trunk/docs/userguide/en/modules/runningexamples.xml 2007-09-27 22:45:39 UTC (rev 3150)
+++ trunk/docs/userguide/en/modules/runningexamples.xml 2007-09-27 22:59:16 UTC (rev 3151)
@@ -1,101 +1,120 @@
+<?xml version="1.0" encoding="UTF-8"?>
<chapter id="examples">
-
<title>Running the Examples</title>
- <para>
- In the directory <literal>docs/examples</literal>, you will find a set of examples demonstrating
- JBoss Messaging working in various examples, they include:
-
- <itemizedlist>
- <listitem>
- <para>docs/example/queue</para>
- <para>This example shows a simple send and receive to a remote queue using a JMS client</para>
- </listitem>
-
- <listitem>
- <para>docs/example/topic</para>
- <para>This example shows a simple send and receive to a remote topic using a JMS client</para>
- </listitem>
-
- <listitem>
- <para>docs/example/mdb</para>
- <para>This example demonstrates usage of an EJB2.1 MDB with JBoss Messaging</para>
- </listitem>
-
- <listitem>
- <para>docs/example/ejb3mdb</para>
- <para>This example demonstrates usage of an EJB3 MDB with JBoss Messaging</para>
- </listitem>
-
- <listitem>
- <para>docs/example/stateless</para>
- <para>This example demonstrates an EJB2.1 stateless session bean interacting with JBoss Messaging</para>
- </listitem>
-
- <listitem>
- <para>docs/example/mdb-failure</para>
- <para>This example demonstrates rollback and redelivery occuring with an EJB2.1 MDB</para>
- </listitem>
-
- <listitem>
- <para>docs/example/secure-socket</para>
- <para>This example demonstrates a JMS client interacting with a JBoss Messaging server
- using SSL encrypted transport</para>
- </listitem>
-
- <listitem>
- <para>docs/example/http</para>
- <para>This example demonstrates a JMS client interacting with a JBoss Messaging server
- tunneling traffic over the HTTP protocol</para>
- </listitem>
-
- <listitem>
- <para>docs/example/web-service</para>
- <para>This example demonstrates JBoss web-service interacting with JBoss Messaging</para>
- </listitem>
-
- <listitem>
- <para>docs/example/distributed-queue</para>
- <para>This example demonstrates a JMS client interacting with a JBoss Messaging distributed
- queue - it requires two JBoss AS instances to be running</para>
- </listitem>
-
- <listitem>
- <para>docs/example/distributed-topic</para>
- <para>This example demonstrates a JMS client interacting with a JBoss Messaging distributed
- topic - it requires two JBoss AS instances to be running</para>
- </listitem>
-
- <listitem>
- <para>docs/example/stateless-clustered</para>
- <para>This example demonstrates a JMS client interacting with clustered EJB2.1
- stateless session bean, which in turn interactes with JBoss Messaging.
- The example uses HAJNDI to lookup the connection factory</para>
- </listitem>
+ <para>In the directory <literal>docs/examples</literal>, you will find a set
+ of examples demonstrating JBoss Messaging working in various examples, they
+ include: <itemizedlist>
+ <listitem>
+ <para>docs/example/queue</para>
- <listitem>
- <para>docs/example/bridge</para>
- <para>This example demonstrates using a message bridge. It deploys a message bridge in JBoss AS which then
-proceeds to move messages from a source to a target queue</para>
- </listitem>
-
- </itemizedlist>
- </para>
-
- <para>It is highly recommended that you familiarise yourself with the examples.</para>
-
- <para>
- Make sure you start the JBoss server(s) before running the examples!
- </para>
-
- <para>The non clustered examples expect a JBoss AS instance to be running with all the default settings
- </para>
-
- <para>The clustered examples expect two JBoss AS instances to running with ports settings as per ports-01 and
- ports-02.</para>
-
- <para>For each example, you can always override the default ports it will try to connect to by editing
- jndi.properties in the particular example directory
- </para>
+ <para>This example shows a simple send and receive to a remote queue
+ using a JMS client</para>
+ </listitem>
-</chapter>
+ <listitem>
+ <para>docs/example/topic</para>
+
+ <para>This example shows a simple send and receive to a remote topic
+ using a JMS client</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/mdb</para>
+
+ <para>This example demonstrates usage of an EJB2.1 MDB with JBoss
+ Messaging</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/ejb3mdb</para>
+
+ <para>This example demonstrates usage of an EJB3 MDB with JBoss
+ Messaging</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/stateless</para>
+
+ <para>This example demonstrates an EJB2.1 stateless session bean
+ interacting with JBoss Messaging</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/mdb-failure</para>
+
+ <para>This example demonstrates rollback and redelivery occuring with
+ an EJB2.1 MDB</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/secure-socket</para>
+
+ <para>This example demonstrates a JMS client interacting with a JBoss
+ Messaging server using SSL encrypted transport</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/http</para>
+
+ <para>This example demonstrates a JMS client interacting with a JBoss
+ Messaging server tunneling traffic over the HTTP protocol</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/web-service</para>
+
+ <para>This example demonstrates JBoss web-service interacting with
+ JBoss Messaging</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/distributed-queue</para>
+
+ <para>This example demonstrates a JMS client interacting with a JBoss
+ Messaging distributed queue - it requires two JBoss AS instances to be
+ running</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/distributed-topic</para>
+
+ <para>This example demonstrates a JMS client interacting with a JBoss
+ Messaging distributed topic - it requires two JBoss AS instances to be
+ running</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/stateless-clustered</para>
+
+ <para>This example demonstrates a JMS client interacting with
+ clustered EJB2.1 stateless session bean, which in turn interactes with
+ JBoss Messaging. The example uses HAJNDI to lookup the connection
+ factory</para>
+ </listitem>
+
+ <listitem>
+ <para>docs/example/bridge</para>
+
+ <para>This example demonstrates using a message bridge. It deploys a
+ message bridge in JBoss AS which then proceeds to move messages from a
+ source to a target queue</para>
+ </listitem>
+ </itemizedlist></para>
+
+ <para>It is highly recommended that you familiarise yourself with the
+ examples.</para>
+
+ <para>Make sure you start the JBoss server(s) before running the
+ examples!</para>
+
+ <para>The non clustered examples expect a JBoss AS instance to be running
+ with all the default settings</para>
+
+ <para>The clustered examples expect two JBoss AS instances to running with
+ ports settings as per ports-01 and ports-02.</para>
+
+ <para>For each example, you can always override the default ports it will
+ try to connect to by editing jndi.properties in the particular example
+ directory</para>
+</chapter>
\ No newline at end of file
More information about the jboss-cvs-commits
mailing list