[jboss-cvs] JBoss Messaging SVN: r4167 - in trunk: docs/examples/jms and 4 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri May 9 07:45:41 EDT 2008
Author: ataylor
Date: 2008-05-09 07:45:40 -0400 (Fri, 09 May 2008)
New Revision: 4167
Added:
trunk/docs/userguide/en/modules/journal.xml
trunk/docs/userguide/en/modules/troubleshooting.xml
Removed:
trunk/docs/userguide/en/modules/bridge.xml
trunk/docs/userguide/en/modules/c_configuration.xml
Modified:
trunk/build-messaging.xml
trunk/docs/examples/jms/build.xml
trunk/docs/examples/jms/src/org/jboss/jms/example/PerfExample.java
trunk/docs/examples/jms/src/org/jboss/jms/example/QueueExample.java
trunk/docs/examples/messaging/src/org/jboss/messaging/example/SimpleExample.java
trunk/docs/userguide/en/master.xml
trunk/docs/userguide/en/modules/about.xml
trunk/docs/userguide/en/modules/configuration.xml
trunk/docs/userguide/en/modules/installation.xml
trunk/docs/userguide/en/modules/introduction.xml
trunk/docs/userguide/en/modules/runningexamples.xml
Log:
new user doc, first pass
Modified: trunk/build-messaging.xml
===================================================================
--- trunk/build-messaging.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/build-messaging.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -78,7 +78,7 @@
<property name="build.distro.lib.dir" value="${build.distro.dir}/lib"/>
<property name="build.distro.config.dir" value="${build.distro.dir}/config"/>
<property name="build.distro.bin.dir" value="${build.distro.dir}/bin"/>
- <property name="build.distro.api.dir" value="${build.distro.dir}/api"/>
+ <property name="build.distro.api.dir" value="${build.distro.dir}/docs/api"/>
<property name="build.distro.examples.dir" value="${build.distro.dir}/docs/examples"/>
<!-- ======================================================================================== -->
<!-- Thirdparty Dependency Definitions -->
Modified: trunk/docs/examples/jms/build.xml
===================================================================
--- trunk/docs/examples/jms/build.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/examples/jms/build.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -43,6 +43,7 @@
<!--perf props-->
<property name="message.count" value="10000"/>
<property name="delivery.mode" value="NON_PERSISTENT"/>
+ <property name="sample.period" value="1"/>
<path id="compile.classpath">
<fileset dir="${lib.dir}">
@@ -104,6 +105,7 @@
<arg value="-s"/>
<arg value="${message.count}"/>
<arg value="${delivery.mode}"/>
+ <arg value="${sample.period}"/>
</java>
</target>
</project>
\ No newline at end of file
Modified: trunk/docs/examples/jms/src/org/jboss/jms/example/PerfExample.java
===================================================================
--- trunk/docs/examples/jms/src/org/jboss/jms/example/PerfExample.java 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/examples/jms/src/org/jboss/jms/example/PerfExample.java 2008-05-09 11:45:40 UTC (rev 4167)
@@ -55,7 +55,8 @@
{
int noOfMessages = Integer.parseInt(args[1]);
int deliveryMode = args[2].equalsIgnoreCase("persistent")? DeliveryMode.PERSISTENT: DeliveryMode.NON_PERSISTENT;
- perfExample.runSender(noOfMessages, deliveryMode);
+ long samplePeriod = Long.parseLong(args[3]);
+ perfExample.runSender(noOfMessages, deliveryMode, samplePeriod);
}
}
@@ -70,7 +71,7 @@
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
}
- public void runSender(int noOfMessage, int deliveryMode)
+ public void runSender(int noOfMessage, int deliveryMode, long samplePeriod)
{
try
{
@@ -81,9 +82,10 @@
PerfParams perfParams = new PerfParams();
perfParams.setNoOfMessagesToSend(noOfMessage);
perfParams.setDeliveryMode(deliveryMode);
+ perfParams.setSamplePeriod(samplePeriod);
m.setObject(perfParams);
producer.send(m);
- scheduler.scheduleAtFixedRate(command, perfParams.getSamplePeriod(), perfParams.getSamplePeriod(), TimeUnit.MILLISECONDS);
+ scheduler.scheduleAtFixedRate(command, perfParams.getSamplePeriod(), perfParams.getSamplePeriod(), TimeUnit.SECONDS);
for (int i = 1; i <= noOfMessage; i++)
{
TextMessage textMessage = session.createTextMessage("" + i);
@@ -184,7 +186,7 @@
params = new PerfParams();
}
log.info("params = " + params);
- scheduler.scheduleAtFixedRate(command, params.getSamplePeriod(), params.getSamplePeriod(), TimeUnit.MILLISECONDS);
+ scheduler.scheduleAtFixedRate(command, params.getSamplePeriod(), params.getSamplePeriod(), TimeUnit.SECONDS);
}
else
{
Modified: trunk/docs/examples/jms/src/org/jboss/jms/example/QueueExample.java
===================================================================
--- trunk/docs/examples/jms/src/org/jboss/jms/example/QueueExample.java 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/examples/jms/src/org/jboss/jms/example/QueueExample.java 2008-05-09 11:45:40 UTC (rev 4167)
@@ -21,6 +21,8 @@
*/
package org.jboss.jms.example;
+import org.jboss.messaging.core.logging.Logger;
+
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.jms.*;
@@ -34,6 +36,7 @@
*/
public class QueueExample
{
+ final static Logger log = Logger.getLogger(QueueExample.class);
public static void main(String[] args)
{
Connection connection = null;
@@ -47,11 +50,13 @@
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(queue);
Message message = session.createTextMessage("This is a text message!");
+ log.info("sending message to queue");
producer.send(message);
MessageConsumer messageConsumer = session.createConsumer(queue);
connection.start();
TextMessage message2 = (TextMessage) messageConsumer.receive(5000);
- System.out.println("message = " + message2.getText());
+ log.info("message received from queue");
+ log.info("message = " + message2.getText());
}
catch (NamingException e)
{
Modified: trunk/docs/examples/messaging/src/org/jboss/messaging/example/SimpleExample.java
===================================================================
--- trunk/docs/examples/messaging/src/org/jboss/messaging/example/SimpleExample.java 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/examples/messaging/src/org/jboss/messaging/example/SimpleExample.java 2008-05-09 11:45:40 UTC (rev 4167)
@@ -60,7 +60,7 @@
try
{
- //create a new server with an invm transport, we could use TCP if needed
+ //create a new server with an TCP transport
ConfigurationImpl configuration = new ConfigurationImpl();
configuration.setTransport(TransportType.TCP);
configuration.setHost("localhost");
Modified: trunk/docs/userguide/en/master.xml
===================================================================
--- trunk/docs/userguide/en/master.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/userguide/en/master.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -1,43 +1,40 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3CR3//EN"
-"../../../lib/docbook-support/support/docbook-dtd/docbookx.dtd" [
-<!ENTITY about SYSTEM "modules/about.xml">
-<!ENTITY introduction SYSTEM "modules/introduction.xml">
-<!ENTITY gettingstarted SYSTEM "modules/gettingstarted.xml">
-<!ENTITY nc_installation SYSTEM "modules/installation.xml">
-<!ENTITY runningexamples SYSTEM "modules/runningexamples.xml">
-<!ENTITY configuration SYSTEM "modules/configuration.xml">
-<!ENTITY c_configuration SYSTEM "modules/c_configuration.xml">
-<!ENTITY recovery_config SYSTEM "modules/recovery_config.xml">
-<!ENTITY bridge SYSTEM "modules/bridge.xml">
-]>
+ "../../../lib/docbook-support/support/docbook-dtd/docbookx.dtd" [
+ <!ENTITY about SYSTEM "modules/about.xml">
+ <!ENTITY introduction SYSTEM "modules/introduction.xml">
+ <!ENTITY gettingstarted SYSTEM "modules/gettingstarted.xml">
+ <!ENTITY nc_installation SYSTEM "modules/installation.xml">
+ <!ENTITY runningexamples SYSTEM "modules/runningexamples.xml">
+ <!ENTITY configuration SYSTEM "modules/configuration.xml">
+ <!ENTITY journal SYSTEM "modules/journal.xml">
+ <!ENTITY troubleshooting SYSTEM "modules/troubleshooting.xml">
+ ]>
<book lang="en">
- <bookinfo>
- <title>JBoss Messaging 2.0 User's Guide</title>
+ <bookinfo>
+ <title>JBoss Messaging 2.0 User's Guide</title>
- <subtitle>Enterprise Messaging from JBoss</subtitle>
+ <subtitle>Enterprise Messaging from JBoss</subtitle>
- </bookinfo>
+ </bookinfo>
- <toc></toc>
+ <toc></toc>
- &about;
+ &about;
- &introduction;
+ &introduction;
- &gettingstarted;
+ &gettingstarted;
- &nc_installation;
+ &nc_installation;
- &runningexamples;
+ &runningexamples;
- &configuration;
+ &configuration;
- &c_configuration;
-
- &recovery_config;
-
- &bridge;
+ &journal;
+ &troubleshooting;
+
</book>
Modified: trunk/docs/userguide/en/modules/about.xml
===================================================================
--- trunk/docs/userguide/en/modules/about.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/userguide/en/modules/about.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -1,28 +1,15 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="about">
- <title>About JBoss Messaging 1.4.0.</title>
- <para>JBoss Messaging is the new enterprise messaging system from JBoss. 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
+ <title>About JBoss Messaging 2.0.0</title>
+ <para>JBoss Messaging is the enterprise messaging system from JBoss.</para>
+ <para>JBoss Messaging is the default JMS provider in the
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>Compared with JBossMQ, JBoss Messaging offers improved performance in
- both single node and clustered environments.</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 can be easily installed in JBoss Application Server
- 4.2 using a few simple steps to remove JBoss MQ and replace with JBoss
- Messaging.</para>
- <para>Once JBoss Messaging becomes the default JMS provider in JBoss
- Application Server, there will be no need to do any manual
- installation.</para>
- <para>From release 1.4.0. onwards JBoss Messaging is designed for JBoss
- 4.2 only and is Java 5.</para>
- <para>The procedure of installing JBoss Messaging into JBoss Application
- Server is detailed in this guide.</para>
+ <para>The procedure of installing and configuring JBoss Messaging is detailed in this guide, along with a set of
+ runnable examples.</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>
Deleted: trunk/docs/userguide/en/modules/bridge.xml
===================================================================
--- trunk/docs/userguide/en/modules/bridge.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/userguide/en/modules/bridge.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -1,332 +0,0 @@
-<?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>
- <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 a 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, and where the
- connection may be unreliable.</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>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>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.</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, the bridge
- will retry connecting to the source and/or target until they come back
- online. When it comes back online it will resume operation as
- normal.</para>
- <para>The bridge can be configured with an optional JMS selector, so it
- will only consume messages matching that JMS 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 logging on both the
- transaction manager and resource side for recovery. 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. 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.messaging.jms.server.bridge.BridgeService"
- name="jboss.messaging:service=Bridge,name=TestBridge"
- xmbean-dd="xmdesc/Bridge-xmbean.xml">
-
- <!-- The JMS provider loader that is used to lookup the source destination -->
- <depends optional-attribute-name="SourceProviderLoader">
- jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
-
- <!-- The JMS provider loader that is used to lookup the target destination -->
- <depends optional-attribute-name="TargetProviderLoader">
- jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
-
- <!-- The JNDI lookup for the source destination -->
- <attribute name="SourceDestinationLookup">/queue/A</attribute>
-
- <!-- The JNDI lookup for the target destination -->
- <attribute name="TargetDestinationLookup">/queue/B</attribute>
-
- <!-- The username to use for the source connection
- <attribute name="SourceUsername">bob</attribute>
- -->
-
- <!-- The password to use for the source connection
- <attribute name="SourcePassword">cheesecake</attribute>
- -->
-
- <!-- The username to use for the target connection
- <attribute name="TargetUsername">mary</attribute>
- -->
-
- <!-- The password to use for the target connection
- <attribute name="TargetPassword">hotdog</attribute>
- -->
-
- <!-- Optional: The Quality Of Service mode to use, one of:
- QOS_AT_MOST_ONCE = 0;
- QOS_DUPLICATES_OK = 1;
- QOS_ONCE_AND_ONLY_ONCE = 2; -->
- <attribute name="QualityOfServiceMode">0</attribute>
-
- <!-- JMS selector to use for consuming messages from the source
- <attribute name="Selector">specify jms selector here</attribute>
- -->
-
- <!-- The maximum number of messages to consume from the source
- before sending to the target -->
- <attribute name="MaxBatchSize">5</attribute>
-
- <!-- The maximum time to wait (in ms) before sending a batch to the target
- even if MaxBatchSize is not exceeded.
- -1 means wait forever -->
- <attribute name="MaxBatchTime">-1</attribute>
-
- <!-- If consuming from a durable subscription this is the subscription name
- <attribute name="SubName">mysub</attribute>
- -->
-
- <!-- If consuming from a durable subscription this is the client ID to use
- <attribute name="ClientID">myClientID</attribute>
- -->
-
- <!-- The number of ms to wait between connection retrues in the event connections
- to source or target fail -->
- <attribute name="FailureRetryInterval">5000</attribute>
-
- <!-- The maximum number of connection retries to make in case of failure,
- before giving up -1 means try forever-->
- <attribute name="MaxRetries">-1</attribute>
-
- <!-- If true then the message id of the message before bridging will be added
- as a header to the message so it is available to the receiver. Can then be
- sent as correlation id to correlate in a distributed request-response -->
- <attribute name="AddMessageIDInHeader">false</attribute>
-
- </mbean>
- </programlisting>
- <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.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>
- <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>
- <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>
- <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
Deleted: trunk/docs/userguide/en/modules/c_configuration.xml
===================================================================
--- trunk/docs/userguide/en/modules/c_configuration.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/userguide/en/modules/c_configuration.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -1,93 +0,0 @@
-<?xml version="1.0" encoding="UTF8"?>
-<chapter id="c_configuration">
- <title>JBoss Messaging Clustering Notes</title>
-
- <section id="c_conf.serverpeerid">
- <title>Unique server peer id</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 is
- assigned a unique server id, as specified in the installation guide.</para>
- <para>Every node deployed must have a unique id, including those in a
- particular LAN cluster, and also those only linked by mesage
- bridges.</para>
- </section>
-
- <section id="c_conf.clustereddests">
- <title>Clustered destinations</title>
- <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>
- </section>
-
- <section id="c_conf.clustereddursubs">
- <title>Clustered durable subs</title>
- <para>JBoss Messaging durable subscriptions 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>
- </section>
-
- <section id="c_conf.clusteredtempdest">
- <title>Clustered temporary destinations</title>
- <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>
- </section>
-
- <section id="c_conf.nonclusteredserver">
- <title>Non clustered servers</title>
- <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>
- </section>
-
-
- <section id="c_conf.orderingincluster">
- <title>Message ordering in the cluster</title>
- <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
- sideeffect of setting this to true is that messages cannot be distributed
- as freely around the cluster</para>
- </section>
-
-
- <section id="c_conf.idempotentops">
- <title>Idempotent operations</title>
- <para>If the call to send a persistent message to a persistent destination
- returns successfully with no exception, then you can be sure that the
- message was persisted. However if the call doesn't return successfully e.g.
- if an exception is thrown, then you *can't be sure the message wasn't
- persisted*. Since the failure might have occurred after persisting the
- message but before writing the response to the caller. This is a common
- attribute of any RPC type call: You can't tell by the call not returning
- that the call didn't actually succeed. Whether it's a web services call, an
- HTTP get request, an ejb invocation the same applies. The trick is to code
- your application so your operations are *idempotent* i.e. they can be
- repeated without getting the system into an inconsistent state. With a
- message system you can do this on the application level, by checking for
- duplicate messages, and discarding them if they arrive. Duplicate checking
- is a very powerful technique that can remove the need for XA transactions
- in many cases.</para>
- </section>
-
-
- <section id="c_conf.clusteredcfs">
- <title>Clustered connection factories</title>
- <para>If the supportsLoadBalancing attribute of the connection factory is set to true then consecutive create connection attempts will round robin between available servers. The first node to try is chosen randomly</para>
- <para>If the supportsFailover attribute of the connection factory is set to true then automatic failover is enabled.
- This will automatically failover from one server to another, transparently to the user, in case of failure.</para>
- <para>If automatic failover is not required or you wish to do manual failover (JBoss MQ style) this can be set to false, and you can supply a standard JMS ExceptionListener on the connection which will be called in case of
- connection failure. You would then need to manually close the connection, lookup a new connection factory from
- HA JNDI and recreate the connection.</para>
-
- </section>
-
-
-</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/configuration.xml
===================================================================
--- trunk/docs/userguide/en/modules/configuration.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/userguide/en/modules/configuration.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -2,1958 +2,614 @@
<chapter id="configuration">
<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>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> (where xx is the name of
- your databse) , <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>
- <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>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>
- <programlisting><mbean code="org.jboss.messaging.jms.server.ServerPeer"
- name="jboss.messaging:service=ServerPeer"
- xmbean-dd="xmdesc/ServerPeer-xmbean.xml">
+ messaging server. The exact definition and implementation of messaging
+ services, such as message destinations, connection factories and security, are
+ specific to JMS providers. JBoss Messaging has its own configuration files
+ to configure these.
+ </para>
+ <para>In this chapter, we discuss how to configure JBoss Messaging, which work together to provide JMS API level
+ services to client applications.
+ </para>
+ <para>JBoss Messaging configuration is spread among several
+ configuration files.
+ <itemizedlist>
+ <listitem>
+ <filename>jbm-configuration.xml</filename>
+ </listitem>
+ <listitem>
+ <filename>jbm-security.xml</filename>
+ </listitem>
+ <listitem>
+ <filename>queues.xml</filename>
+ </listitem>
+ <listitem>
+ <filename>jbm-jndi.xml</filename>
+ </listitem>
+ <listitem>
+ <filename>jbm-standalone-beans.xml</filename>
+ or
+ <filename>jbm-beans.xml</filename>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>The next sections explain each configuration file in detail</para>
- <!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer -->
+ <section id="configuration.main">
+ <title>jbm-configuration.xml</title>
+ <para>This configuration file is the core configuration for the JBM server. The following is an example of a
+ typical configuration
+ </para>
+ <programlisting>
+ <![CDATA[
+ <deployment>
+ <configuration>
- <attribute name="ServerPeerID">0</attribute>
-
- <!-- The default JNDI context to use for queues when they are deployed without specifying one -->
-
- <attribute name="DefaultQueueJNDIContext">/queue</attribute>
-
- <!-- The default JNDI context to use for topics when they are deployed without specifying one -->
-
- <attribute name="DefaultTopicJNDIContext">/topic</attribute>
+ <!-- TODO!! Should specify all available properties in here -->
- <attribute name="PostOffice">jboss.messaging:service=PostOffice</attribute>
-
- <!-- The JAAS security domain to use for JBoss Messaging -->
-
- <attribute name="SecurityDomain">java:/jaas/messaging</attribute>
-
- <!-- The default security configuration to apply to destinations - this can be overridden on a per destination basis -->
-
- <attribute name="DefaultSecurityConfig">
- <security>
- <role name="guest" read="true" write="true" create="true"/>
- </security>
- </attribute>
-
- <!-- The default Dead Letter Queue (DLQ) to use for destinations.
- This can be overridden on a per destinatin basis -->
-
- <attribute name="DefaultDLQ">jboss.messaging.destination:service=Queue,name=DLQ</attribute>
-
- <!-- The default maximum number of times to attempt delivery of a message before sending to the DLQ (if configured).
- This can be overridden on a per destinatin basis -->
-
- <attribute name="DefaultMaxDeliveryAttempts">10</attribute>
-
- <!-- The default Expiry Queue to use for destinations. This can be overridden on a per destinatin basis -->
-
- <attribute name="DefaultExpiryQueue">jboss.messaging.destination:service=Queue,name=ExpiryQueue</attribute>
-
- <!-- The default redelivery delay to impose. This can be overridden on a per destination basis -->
-
- <attribute name="DefaultRedeliveryDelay">0</attribute>
-
- <!-- The periodicity of the message counter manager enquiring on queues for statistics -->
-
- <attribute name="MessageCounterSamplePeriod">5000</attribute>
-
- <!-- The maximum amount of time for a client to wait for failover to start on the server side after
- it has detected failure -->
-
- <attribute name="FailoverStartTimeout">60000</attribute>
-
- <!-- The maximum amount of time for a client to wait for failover to complete on the server side after
- it has detected failure -->
-
- <attribute name="FailoverCompleteTimeout">300000</attribute>
-
- <!-- The maximum number of days results to maintain in the message counter history -->
-
- <attribute name="DefaultMessageCounterHistoryDayLimit">-1</attribute>
-
- <!-- The name of the connection factory to use for creating connections between nodes to pull messages -->
-
- <attribute name="ClusterPullConnectionFactoryName">jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory</attribute>
-
- <!-- When redistributing messages in the cluster. Do we need to preserve the order of messages received
- by a particular consumer from a particular producer? -->
-
- <attribute name="DefaultPreserveOrdering">false</attribute>
-
- <!-- Max. time to hold previously delivered messages back waiting for clients to reconnect after failover -->
-
- <attribute name="RecoverDeliveriesTimeout">300000</attribute>
-
- <!-- The password used by the message sucker connections to create connections.
- THIS SHOULD ALWAYS BE CHANGED AT INSTALL TIME TO SECURE SYSTEM
- <attribute name="SuckerPassword"></attribute>
- -->
+ <strict-tck>true</strict-tck>
- <depends optional-attribute-name="PersistenceManager">jboss.messaging:service=PersistenceManager</depends>
-
- <depends optional-attribute-name="JMSUserManager">jboss.messaging:service=JMSUserManager</depends>
-
- <depends>jboss.messaging:service=Connector,transport=bisocket</depends>
+ <clustered>false</clustered>
- </mbean>
+ <scheduled-executor-max-pool-size>30</scheduled-executor-max-pool-size>
+
+ <require-destinations>true</require-destinations>
+
+ <!-- Remoting configuration -->
+
+ <!-- one of: TCP, INVM -->
+ <!-- INVM: the server is accessible only by clients in the same VM
+ (no sockets are opened) -->
+ <remoting-transport>TCP</remoting-transport>
+
+ <remoting-bind-address>5400</remoting-bind-address>
+
+ <remoting-host>localhost</remoting-host>
+
+ <!-- timeout in seconds -->
+ <remoting-timeout>5</remoting-timeout>
+
+ <!-- true to disable invm communication when the client and the server are in the
+ same JVM. -->
+ <!-- it is not allowed to disable invm communication when the remoting-transport
+ is set to INVM -->
+ <remoting-disable-invm>false</remoting-disable-invm>
+
+ <!-- Enable/Disable Nagle's Algorithm (resp. true/false) -->
+ <!-- This setting is taken into account only when remoting-transport is set to
+ TCP -->
+ <remoting-tcp-nodelay>false</remoting-tcp-nodelay>
+
+ <!-- Set the TCP Receive Buffer size (SO_RCVBUF). -->
+ <!-- Set it to -1 if you want to use the value hinted by the Operating System -->
+ <!-- This setting is taken into account only when remoting-transport is set to
+ TCP -->
+ <remoting-tcp-receive-buffer-size>-1</remoting-tcp-receive-buffer-size>
+
+ <!-- Set the TCP Send Buffer size (SO_SNDBUF).-->
+ <!-- Set it to -1 if you want to use the value hinted by the Operating System-->
+ <!-- This setting is taken into account only when remoting-transport is set to
+ TCP -->
+ <remoting-tcp-send-buffer-size>-1</remoting-tcp-send-buffer-size>
+
+ <!-- if ssl is enabled, all remoting-ssl-* properties must be set -->
+ <remoting-enable-ssl>false</remoting-enable-ssl>
+
+ <remoting-ssl-keystore-path>messaging.keystore</remoting-ssl-keystore-path>
+
+ <remoting-ssl-keystore-password>secureexample</remoting-ssl-keystore-password>
+
+ <remoting-ssl-truststore-path>messaging.truststore</remoting-ssl-truststore-path>
+
+ <remoting-ssl-truststore-password>secureexample</remoting-ssl-truststore-password>
+
+ <!-- Storage configuration -->
+
+ <bindings-directory>${user.home}/jbm-test/data/bindings</bindings-directory>
+
+ <create-bindings-dir>true</create-bindings-dir>
+
+ <journal-directory>${user.home}/jbm-test/data/journal</journal-directory>
+
+ <create-journal-dir>true</create-journal-dir>
+
+ <journal-type>asyncio</journal-type>
+
+ <journal-sync>true</journal-sync>
+
+ <journal-file-size>10485760</journal-file-size>
+
+ <journal-min-files>10</journal-min-files>
+
+ <journal-task-period>5000</journal-task-period>
+
+ </configuration>
+
+ </deployment>
+]]>
</programlisting>
- <section id="conf.serverpeer.attributes">
- <title>ServerPeer attributes</title>
- <para>We now discuss the MBean attributes of the ServerPeer
- MBean.</para>
- <section id="conf.serverpeer.attributes.serverpeerid">
- <title>ServerPeerID</title>
- <para>The unique id of the server peer. Every node you deploy MUST
- have a unique id. This applies whether the different nodes form a
- cluster, or are only linked via a message bridge. The id must be a
- valid integer.</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultqueuejndicontext">
- <title>DefaultQueueJNDIContext</title>
- <para>The default JNDI context to use when binding queues.
- Defaults to /queue.</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultopicjndicontext">
- <title>DefaultTopicJNDIContext</title>
- <para>The default JNDI context to use when binding topics.wa
- Defaults to /topic.</para>
- </section>
- <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>
- <section id="conf.serverpeer.attributes.securitydomain">
- <title>SecurityDomain</title>
- <para>The JAAS security domain to be used by this server
- peer</para>
- </section>
- <section id="conf.serverpeer.attributes.defaultsecurity">
- <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>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>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>
- </section>
- <section id="conf.serverpeer.attributes.defaultdlq">
- <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. 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>
- <section id="conf.serverpeer.attributes.defaultmaxdeliveryattempts">
- <title>DefaultMaxDeliveryAttempts</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>
- </section>
- <section id="conf.serverpeer.attributes.defaultexpiryqueue">
- <title>DefaultExpiryQueue</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. 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.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>
- <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>
- <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>
- <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>
- <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>
- <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.defaultpreserveordering">
- <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>
- <section id="conf.serverpeer.attributes.recoverdeliveriestimeout">
- <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>
- </section>
- <section id="conf.serverpeer.attributes.suckerpassword">
- <title>SuckerPassword</title>
- <para>JBoss Messaging internally makes connections between nodes
- in order to redistribute messages between clustered destinations.
- 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. This value MUST be changed at install time.
- </warning></para>
- </section>
- <section id="conf.serverpeer.attributes.stricttck">
- <title>StrictTCK</title>
- <para>Set to true if you want strict JMS TCK semantiocs</para>
- </section>
- <section id="conf.serverpeer.attributes.destinations">
- <title>Destinations</title>
- <para>Returns a list of the destinations (queues and topics)
- currently deployed.</para>
- </section>
- <section id="conf.serverpeer.attributes.messagecounters">
- <title>MessageCounters</title>
- <para>JBoss Messaging provides a message counter for each
- queue.</para>
- </section>
- <section id="conf.serverpeer.attributes.messagecounterstatistics">
- <title>MessageCountersStatistics</title>
- <para>JBoss Messaging provides statistics for each message counter
- for each queue.</para>
- </section>
- <section id="conf.serverpeer.attributes.supportsfailover">
- <title>SupportsFailover</title>
- <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>
- <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>
- <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>
- <section id="conf.serverpeer.operations.deployQueue">
- <title>DeployQueue</title>
- <para>This operation lets you programmatically deploy a
- queue.</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>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 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 id="conf.serverpeer.operations.undeployQueue">
- <title>UndeployQueue</title>
- <para>This operation lets you programmatically undeploy a
- queue.</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>
- <section id="conf.serverpeer.operations.destroyQueue">
- <title>DestroyQueue</title>
- <para>This operation lets you programmatically destroy a
- queue.</para>
- <para>The queue is undeployed and then all its data is
- destroyed from the database.</para>
- <warning>
- Be careful when using this method since it will delete all data for the queue.
- </warning>
- <para>This operation returns <literal>true</literal> if the
- queue was successfully destroyed. otherwise it returns
- <literal>false</literal>.</para>
- </section>
- <section id="conf.serverpeer.operations.deployTopic">
- <title>DeployTopic</title>
- <para>This operation lets you programmatically deploy a
- topic.</para>
- <para>There are two overloaded versions of this
- operation.</para>
- <para>If the topic 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>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>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 id="conf.serverpeer.operations.undeployTopic">
- <title>UndeployTopic</title>
- <para>This operation lets you programmatically undeploy a
- topic.</para>
- <para>The queue is undeployed but is NOT removed from
- persistent storage.</para>
- <para>This operation returns <literal>true</literal> if the
- topic was successfully undeployed. otherwise it returns
- <literal>false</literal>.</para>
- </section>
- <section id="conf.serverpeer.operations.destroyTopic">
- <title>DestroyTopic</title>
- <para>This operation lets you programmatically destroy a
- topic.</para>
- <para>The topic is undeployed and then all its data is
- destroyed from the database.</para>
- <warning>
- Be careful when using this method since it will delete all data for the topic.
- </warning>
- <para>This operation returns <literal>true</literal> if the
- topic was successfully destroyed. otherwise it returns
- <literal>false</literal>.</para>
- </section>
- <section id="conf.serverpeer.operations.listmessagecountersashtml">
- <title>ListMessageCountersHTML</title>
- <para>This operation returns message counters in an easy to
- display HTML format.</para>
- </section>
- <section id="conf.serverpeer.operations.resetallmessagecounters">
- <title>ResetAllMesageCounters</title>
- <para>This operation resets all message counters to
- zero.</para>
- </section>
- <section id="conf.serverpeer.operations.resetallmessagecounterhistories">
- <title>ResetAllMesageCounters</title>
- <para>This operation resets all message counter histories to
- zero.</para>
- </section>
- <section id="conf.serverpeer.operations.enablemessagecounters">
- <title>EnableMessageCounters</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>
- </section>
- </section>
+ <para>The available configuration attributes are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>strict-tck</para>
+ </listitem>
+ <listitem>
+ <para>clustered</para>
+ </listitem>
+ <listitem>
+ <para>scheduled-executor-max-pool-size</para>
+ </listitem>
+ <listitem>
+ <para>require-destinations</para>
+ </listitem>
+ <listitem>
+ <para>remoting-transport</para>
+ </listitem>
+ <listitem>
+ <para>remoting-bind-address</para>
+ </listitem>
+ <listitem>
+ <para>remoting-host</para>
+ </listitem>
+ <listitem>
+ <para>remoting-timeout</para>
+ </listitem>
+ <listitem>
+ <para>remoting-disable-invm</para>
+ </listitem>
+ <listitem>
+ <para>remoting-tcp-nodelay</para>
+ </listitem>
+ <listitem>
+ <para>remoting-tcp-receive-buffer-size</para>
+ </listitem>
+ <listitem>
+ <para>remoting-tcp-send-buffer-size</para>
+ </listitem>
+ <listitem>
+ <para>remoting-ssl-keystore-path>messaging.keystore</para>
+ </listitem>
+ <listitem>
+ <para>remoting-ssl-keystore-password</para>
+ </listitem>
+ <listitem>
+ <para>remoting-ssl-truststore-path</para>
+ </listitem>
+ <listitem>
+ <para>remoting-ssl-truststore-password</para>
+ </listitem>
+ <listitem>
+ <para>bindings-directory</para>
+ </listitem>
+ <listitem>
+ <para>create-bindings-dir</para>
+ </listitem>
+ <listitem>
+ <para>journal-type</para>
+ </listitem>
+ <listitem>
+ <para>journal-sync</para>
+ </listitem>
+ <listitem>
+ <para>journal-file-size</para>
+ </listitem>
+ <listitem>
+ <para>journal-min-files</para>
+ </listitem>
+ <listitem>
+ <para>journal-task-period</para>
+ </listitem>
+ </itemizedlist>
</section>
- <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>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>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>
- <section id="conf.postoffice">
- <title>Configuring the Post office</title>
- <para>It is the job of the post office to route messages to their
- destination(s).</para>
- <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>
- <para>The post office also handles the persistence for the mapping of
- addresses.</para>
- <para>JBoss Messaging post-offices 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>
+ <section id="configuration.security">
+ <title>jbm-security.xml</title>
+ <para>This configuration file is used to configure users and roles when JBM is running in standalone mode using
+ the JBM Security Manager. The Security manager used is a pluggable component whose implementation can be
+ changed by
+ configuring the appropriate beans configuration file. Refer to the beans configuration section on how to do
+ this.
+ A typical jbm-security.xml config looks like:
+ </para>
<programlisting>
- <mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService"
- name="jboss.messaging:service=PostOffice"
- xmbean-dd="xmdesc/MessagingPostOffice-xmbean.xml">
-
- <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
-
- <depends>jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>
-
- <depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>
-
- <!-- The name of the post office -->
-
- <attribute name="PostOfficeName">JMS post office</attribute>
-
- <!-- The datasource used by the post office to access it's binding information -->
-
- <attribute name="DataSource">java:/DefaultDS</attribute>
-
- <!-- If true will attempt to create tables and indexes on every start-up -->
-
- <attribute name="CreateTablesOnStartup">true</attribute>
-
- <attribute name="SqlProperties"><![CDATA[
-CREATE_POSTOFFICE_TABLE=CREATE TABLE JBM_POSTOFFICE (POSTOFFICE_NAME VARCHAR(255), NODE_ID INTEGER, QUEUE_NAME VARCHAR(255), COND VARCHAR(1023), SELECTOR VARCHAR(1023), CHANNEL_ID BIGINT, CLUSTERED CHAR(1), ALL_NODES CHAR(1), PRIMARY KEY(POSTOFFICE_NAME, NODE_ID, QUEUE_NAME)) ENGINE = INNODB
-INSERT_BINDING=INSERT INTO JBM_POSTOFFICE (POSTOFFICE_NAME, NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED, ALL_NODES) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
-DELETE_BINDING=DELETE FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=? AND QUEUE_NAME=?
-LOAD_BINDINGS=SELECT QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED, ALL_NODES FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=?
- ]]></attribute>
-
- <!-- This post office is clustered. If you don't want a clustered post office then set to false -->
-
- <attribute name="Clustered">true</attribute>
-
- <!-- All the remaining properties only have to be specified if the post office is clustered.
- You can safely comment them out if your post office is non clustered -->
-
- <!-- The JGroups group name that the post office will use -->
-
- <attribute name="GroupName">${jboss.messaging.groupname:MessagingPostOffice}</attribute>
-
- <!-- Max time to wait for state to arrive when the post office joins the cluster -->
-
- <attribute name="StateTimeout">5000</attribute>
-
- <!-- Max time to wait for a synchronous call to node members using the MessageDispatcher -->
-
- <attribute name="CastTimeout">50000</attribute>
-
- <!-- JGroups stack configuration for the data channel - used for sending data across the cluster -->
-
- <!-- By default we use the TCP stack for data -->
- <attribute name="DataChannelConfig">
- <config>
- <TCP start_port="7900"
- loopback="true"
- recv_buf_size="20000000"
- send_buf_size="640000"
- discard_incompatible_packets="true"
- max_bundle_size="64000"
- max_bundle_timeout="30"
- use_incoming_packet_handler="true"
- use_outgoing_packet_handler="false"
- down_thread="false" up_thread="false"
- enable_bundling="false"
- use_send_queues="false"
- sock_conn_timeout="300"
- skip_suspected_members="true"/>
- <MPING timeout="4000"
- bind_to_all_interfaces="true"
- mcast_addr="${jboss.messaging.datachanneludpaddress:228.6.6.6}"
- mcast_port="${jboss.messaging.datachanneludpport:45567}"
- ip_ttl="8"
- num_initial_members="2"
- num_ping_requests="1"/>
- <MERGE2 max_interval="100000"
- down_thread="false" up_thread="false" min_interval="20000"/>
- <FD_SOCK down_thread="false" up_thread="false"/>
- <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
- <pbcast.NAKACK max_xmit_size="60000"
- use_mcast_xmit="false" gc_lag="0"
- retransmit_timeout="300,600,1200,2400,4800"
- down_thread="false" up_thread="false"
- discard_delivered_msgs="true"/>
- <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
- down_thread="false" up_thread="false"
- max_bytes="400000"/>
- <pbcast.GMS print_local_addr="true" join_timeout="3000"
- down_thread="false" up_thread="false"
- join_retry_timeout="2000" shun="false"
- view_bundling="true"/>
- </config>
- </attribute>
-
- <!-- JGroups stack configuration to use for the control channel - used for control messages -->
-
- <!-- We use udp stack for the control channel -->
- <attribute name="ControlChannelConfig">
- <config>
- <UDP
- mcast_addr="${jboss.messaging.controlchanneludpaddress:228.7.7.7}"
- mcast_port="${jboss.messaging.controlchanneludpport:45568}"
- tos="8"
- ucast_recv_buf_size="20000000"
- ucast_send_buf_size="640000"
- mcast_recv_buf_size="25000000"
- mcast_send_buf_size="640000"
- loopback="false"
- discard_incompatible_packets="true"
- max_bundle_size="64000"
- max_bundle_timeout="30"
- use_incoming_packet_handler="true"
- use_outgoing_packet_handler="false"
- ip_ttl="2"
- down_thread="false" up_thread="false"
- enable_bundling="false"/>
- <PING timeout="2000"
- down_thread="false" up_thread="false" num_initial_members="3"/>
- <MERGE2 max_interval="100000"
- down_thread="false" up_thread="false" min_interval="20000"/>
- <FD_SOCK down_thread="false" up_thread="false"/>
- <FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true"/>
- <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
- <pbcast.NAKACK max_xmit_size="60000"
- use_mcast_xmit="false" gc_lag="0"
- retransmit_timeout="300,600,1200,2400,4800"
- down_thread="false" up_thread="false"
- discard_delivered_msgs="true"/>
- <UNICAST timeout="300,600,1200,2400,3600"
- down_thread="false" up_thread="false"/>
- <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
- down_thread="false" up_thread="false"
- max_bytes="400000"/>
- <pbcast.GMS print_local_addr="true" join_timeout="3000" use_flush="true" flush_timeout="3000"
- down_thread="false" up_thread="false"
- join_retry_timeout="2000" shun="false"
- view_bundling="true"/>
- <FRAG2 frag_size="60000" down_thread="false" up_thread="false"/>
- <pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="true" flush_timeout="3000"/>
- <pbcast.FLUSH down_thread="false" up_thread="false" timeout="20000" auto_flush_conf="false"/>
- </config>
- </attribute>
-
- </mbean>
+ <![CDATA[
+ <deployment>
+ <user name="guest" password="guest">
+ <role name="guest"/>
+ </user>
+ </deployment>
+ ]]>
</programlisting>
- <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.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.postoffice.attributes.createtables">
- <title>CreateTablesOnStartup</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>
- <section id="conf.postoffice.attributes.postofficename">
- <title>PostOfficeName</title>
- <para>The name of the post office.</para>
- </section>
- <section id="conf.postoffice.attributes.nodeidview">
- <title>NodeIDView</title>
- <para>This returns set containing the node ids of all the nodes in
- the cluster.</para>
- </section>
- <section id="conf.postoffice.attributes.groupname">
- <title>GroupName</title>
- <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.clustered">
- <title>Clustered</title>
- <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.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.maxconcurrentreplications">
- <title>MaxConcurrentReplications</title>
- <para>The maximum number of concurrent replication requests to
- make before blocking for replies to come back. This prevents us
- overwhelming JGroups. This is rarely a good reason to change
- this.</para>
- <para>The default value is <literal>50</literal></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.datachannelconfig">
- <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 and for replicating
- session data.</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>
+ <para>The available configuration attributes are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>user</para>
+ <para>The user to add to the security manager. This must have the attribute 'name' and 'password' set.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>role</para>
+ <para>A role that the user has, a user may have multiple roles configured.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
</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 xxx
- corresponds to the database name. 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>
+ <section id="configuration.queues">
+ <title>queues.xml</title>
+ <para>This configuration file is used to configure the security and settings for destinations. These are matched
+ against a destination using an hierarchical style match that supports both wild cards ('*') and word
+ replacement ('^')
+ </para>
+ <para>For instance a destination withname 'queuejms.aqueue.myQueue' would match against 'queuejms.*',
+ 'queuejms.aqueue.^', 'queuejms.^.myQueue' and obviously 'queuejms.aqueue.myQueue'. If a destination has
+ multiple
+ matches then the most precise match is used
+ </para>
<programlisting>
- <mbean code="org.jboss.messaging.core.jmx.JDBCPersistenceManagerService"
- name="jboss.messaging:service=PersistenceManager"
- xmbean-dd="xmdesc/JDBCPersistenceManager-xmbean.xml">
-
- <depends>jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>
-
- <depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>
-
- <!-- The datasource to use for the persistence manager -->
-
- <attribute name="DataSource">java:/DefaultDS</attribute>
-
- <!-- If true will attempt to create tables and indexes on every start-up -->
-
- <attribute name="CreateTablesOnStartup">true</attribute>
-
- <!-- If true then will use JDBC batch updates -->
-
- <attribute name="UsingBatchUpdates">true</attribute>
-
- <attribute name="SqlProperties"><![CDATA[
- CREATE_DUAL=CREATE TABLE JBM_DUAL (DUMMY INTEGER, PRIMARY KEY (DUMMY)) ENGINE = INNODB
- CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (CHANNEL_ID BIGINT, MESSAGE_ID BIGINT, TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INTEGER, SCHED_DELIVERY BIGINT, PRIMARY KEY(CHANNEL_ID, MESSAGE_ID)) ENGINE = INNODB
- CREATE_IDX_MESSAGE_REF_TX=CREATE INDEX JBM_MSG_REF_TX ON JBM_MSG_REF (TRANSACTION_ID)
- CREATE_IDX_MESSAGE_REF_ORD=CREATE INDEX JBM_MSG_REF_ORD ON JBM_MSG_REF (ORD)
- CREATE_IDX_MESSAGE_REF_PAGE_ORD=CREATE INDEX JBM_MSG_REF_PAGE_ORD ON JBM_MSG_REF (PAGE_ORD)
- CREATE_IDX_MESSAGE_REF_MESSAGE_ID=CREATE INDEX JBM_MSG_REF_MESSAGE_ID ON JBM_MSG_REF (MESSAGE_ID)
- CREATE_IDX_MESSAGE_REF_SCHED_DELIVERY=CREATE INDEX JBM_MSG_REF_SCHED_DELIVERY ON JBM_MSG_REF (SCHED_DELIVERY)
- CREATE_MESSAGE=CREATE TABLE JBM_MSG (MESSAGE_ID BIGINT, RELIABLE CHAR(1), EXPIRATION BIGINT, TIMESTAMP BIGINT, PRIORITY TINYINT, TYPE TINYINT, HEADERS MEDIUMBLOB, PAYLOAD LONGBLOB, PRIMARY KEY (MESSAGE_ID)) ENGINE = INNODB
- CREATE_IDX_MESSAGE_TIMESTAMP=CREATE INDEX JBM_MSG_REF_TIMESTAMP ON JBM_MSG (TIMESTAMP)
- CREATE_TRANSACTION=CREATE TABLE JBM_TX (NODE_ID INTEGER, TRANSACTION_ID BIGINT, BRANCH_QUAL VARBINARY(254), FORMAT_ID INTEGER, GLOBAL_TXID VARBINARY(254), PRIMARY KEY (TRANSACTION_ID)) ENGINE = INNODB
- CREATE_COUNTER=CREATE TABLE JBM_COUNTER (NAME VARCHAR(255), NEXT_ID BIGINT, PRIMARY KEY(NAME)) ENGINE = INNODB
- INSERT_DUAL=INSERT INTO JBM_DUAL VALUES (1)
- CHECK_DUAL=SELECT 1 FROM JBM_DUAL
- INSERT_MESSAGE_REF=INSERT INTO JBM_MSG_REF (CHANNEL_ID, MESSAGE_ID, TRANSACTION_ID, STATE, ORD, PAGE_ORD, DELIVERY_COUNT, SCHED_DELIVERY) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
- DELETE_MESSAGE_REF=DELETE FROM JBM_MSG_REF WHERE MESSAGE_ID=? AND CHANNEL_ID=? AND STATE='C'
- UPDATE_MESSAGE_REF=UPDATE JBM_MSG_REF SET TRANSACTION_ID=?, STATE='-' WHERE MESSAGE_ID=? AND CHANNEL_ID=? AND STATE='C'
- UPDATE_PAGE_ORDER=UPDATE JBM_MSG_REF SET PAGE_ORD = ? WHERE MESSAGE_ID=? AND CHANNEL_ID=?
- COMMIT_MESSAGE_REF1=UPDATE JBM_MSG_REF SET STATE='C', TRANSACTION_ID = NULL WHERE TRANSACTION_ID=? AND STATE='+'
- COMMIT_MESSAGE_REF2=DELETE FROM JBM_MSG_REF WHERE TRANSACTION_ID=? AND STATE='-'
- ROLLBACK_MESSAGE_REF1=DELETE FROM JBM_MSG_REF WHERE TRANSACTION_ID=? AND STATE='+'
- ROLLBACK_MESSAGE_REF2=UPDATE JBM_MSG_REF SET STATE='C', TRANSACTION_ID = NULL WHERE TRANSACTION_ID=? AND STATE='-'
- LOAD_PAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, PAGE_ORD, SCHED_DELIVERY FROM JBM_MSG_REF WHERE CHANNEL_ID = ? AND PAGE_ORD BETWEEN ? AND ? ORDER BY PAGE_ORD
- LOAD_UNPAGED_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? AND PAGE_ORD IS NULL ORDER BY ORD
- LOAD_REFS=SELECT MESSAGE_ID, DELIVERY_COUNT, SCHED_DELIVERY FROM JBM_MSG_REF WHERE STATE = 'C' AND CHANNEL_ID = ? ORDER BY ORD
- UPDATE_REFS_NOT_PAGED=UPDATE JBM_MSG_REF SET PAGE_ORD = NULL WHERE PAGE_ORD BETWEEN ? AND ? AND CHANNEL_ID=?
- SELECT_MIN_MAX_PAGE_ORD=SELECT MIN(PAGE_ORD), MAX(PAGE_ORD) FROM JBM_MSG_REF WHERE CHANNEL_ID = ?
- SELECT_EXISTS_REF_MESSAGE_ID=SELECT MESSAGE_ID FROM JBM_MSG_REF WHERE MESSAGE_ID = ?
- UPDATE_DELIVERY_COUNT=UPDATE JBM_MSG_REF SET DELIVERY_COUNT = ? WHERE CHANNEL_ID = ? AND MESSAGE_ID = ?
- UPDATE_CHANNEL_ID=UPDATE JBM_MSG_REF SET CHANNEL_ID = ? WHERE CHANNEL_ID = ?
- LOAD_MESSAGES=SELECT MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, HEADERS, PAYLOAD, TYPE FROM JBM_MSG
- INSERT_MESSAGE=INSERT INTO JBM_MSG (MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, TYPE, HEADERS, PAYLOAD) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
- INSERT_MESSAGE_CONDITIONAL=INSERT INTO JBM_MSG (MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, TYPE, INST_TIME) SELECT ?, ?, ?, ?, ?, ?, ? FROM JBM_DUAL WHERE NOT EXISTS (SELECT MESSAGE_ID FROM JBM_MSG WHERE MESSAGE_ID = ?)
- UPDATE_MESSAGE_4CONDITIONAL=UPDATE JBM_MSG SET HEADERS=?, PAYLOAD=? WHERE MESSAGE_ID=?
- INSERT_MESSAGE_CONDITIONAL_FULL=INSERT INTO JBM_MSG (MESSAGE_ID, RELIABLE, EXPIRATION, TIMESTAMP, PRIORITY, TYPE, HEADERS, PAYLOAD) SELECT ?, ?, ?, ?, ?, ?, ?, ? FROM JBM_DUAL WHERE NOT EXISTS (SELECT MESSAGE_ID FROM JBM_MSG WHERE MESSAGE_ID = ?)
- MESSAGE_ID_COLUMN=MESSAGE_ID
- DELETE_MESSAGE=DELETE FROM JBM_MSG WHERE MESSAGE_ID = ? AND NOT EXISTS (SELECT * FROM JBM_MSG_REF WHERE JBM_MSG_REF.MESSAGE_ID = ?)
- INSERT_TRANSACTION=INSERT INTO JBM_TX (NODE_ID, TRANSACTION_ID, BRANCH_QUAL, FORMAT_ID, GLOBAL_TXID) VALUES(?, ?, ?, ?, ?)
- DELETE_TRANSACTION=DELETE FROM JBM_TX WHERE NODE_ID = ? AND TRANSACTION_ID = ?
- SELECT_PREPARED_TRANSACTIONS=SELECT TRANSACTION_ID, BRANCH_QUAL, FORMAT_ID, GLOBAL_TXID FROM JBM_TX WHERE NODE_ID = ?
- SELECT_MESSAGE_ID_FOR_REF=SELECT MESSAGE_ID, CHANNEL_ID FROM JBM_MSG_REF WHERE TRANSACTION_ID = ? AND STATE = '+' ORDER BY ORD
- SELECT_MESSAGE_ID_FOR_ACK=SELECT MESSAGE_ID, CHANNEL_ID FROM JBM_MSG_REF WHERE TRANSACTION_ID = ? AND STATE = '-' ORDER BY ORD
- UPDATE_COUNTER=UPDATE JBM_COUNTER SET NEXT_ID = ? WHERE NAME=?
- SELECT_COUNTER=SELECT NEXT_ID FROM JBM_COUNTER WHERE NAME=? FOR UPDATE
- INSERT_COUNTER=INSERT INTO JBM_COUNTER (NAME, NEXT_ID) VALUES (?, ?)
- SELECT_ALL_CHANNELS=SELECT DISTINCT(CHANNEL_ID) FROM JBM_MSG_REF
- UPDATE_TX=UPDATE JBM_TX SET NODE_ID=? WHERE NODE_ID=?
- ]]></attribute>
-
- <!-- The maximum number of parameters to include in a prepared statement -->
-
- <attribute name="MaxParams">500</attribute>
-
- </mbean>
-
- </programlisting>
- <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>
- <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>
- <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.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>
- <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>
- <section id="conf.persistencemanager.attributes.supportsblobonselect">
- <title>SupportsBlobOnSelect</title>
- <para>Oracle (and possibly other databases) is known to not allow
- BLOBs to be inserted using a INSERT INTO ... SELECT FROM
- statement, and requires a two stage conditional insert of
- messages. If this value is false then such a two stage insert will
- be used.</para>
- <para>By default the value of
- <literal>SupportsBlobOnSelect</literal> attribute is set to
- <literal>true</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.messaging.jms.server.plugin.JDBCJMSUserManagerService"
- name="jboss.messaging:service=JMSUserManager"
- xmbean-dd="xmdesc/JMSUserManager-xmbean.xml">
- <depends>jboss.jca:service=DataSourceBinding,name=DefaultDS</depends>
- <depends optional-attribute-name="TransactionManager">
- jboss:service=TransactionManager
- </depends>
- <attribute name="DataSource">java:/DefaultDS</attribute>
- <attribute name="CreateTablesOnStartup">true</attribute>
- <attribute name="SqlProperties"><![CDATA[
- CREATE_USER_TABLE=CREATE TABLE JBM_USER (USER_ID VARCHAR(32) NOT NULL,
- PASSWD VARCHAR(32) NOT NULL, CLIENTID VARCHAR(128),
- PRIMARY KEY(USER_ID)) ENGINE = INNODB
- CREATE_ROLE_TABLE=CREATE TABLE JBM_ROLE (ROLE_ID VARCHAR(32) NOT NULL,
- USER_ID VARCHAR(32) NOT NULL, PRIMARY KEY(USER_ID, ROLE_ID))
- ENGINE = INNODB
- SELECT_PRECONF_CLIENTID=SELECT CLIENTID FROM JBM_USER WHERE USER_ID=?
- POPULATE.TABLES.1=INSERT INTO JBM_USER (USER_ID,PASSWD,CLIENTID)
- VALUES ('dilbert','dogbert','dilbert-id')
- ]]></attribute>
- </mbean>
- </programlisting>
- <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>
- <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>
- <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.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>
- </section>
- <!-- end conf.jmsusermanager.attributes -->
- </section>
- <!-- end.conf.jmsusermanager -->
- <section id="conf.destination">
- <title>Configuring Destinations</title>
- <section id="conf.preconf.destinations">
- <title>Pre-configured 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>
- <programlisting>
- <!--
- The Default Dead Letter Queue. This destination is a dependency of an EJB MDB container.
- -->
+ <![CDATA[
+ <deployment>
- <mbean code="org.jboss.messaging.jms.server.destination.QueueService"
- name="jboss.messaging.destination:service=Queue,name=DLQ"
- xmbean-dd="xmdesc/Queue-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- </mbean>
+ <security match="topicjms.testTopic">
+ <permission type="create" roles="durpublisher"/>
+ <permission type="read" roles="guest,publisher,durpublisher"/>
+ <permission type="write" roles="guest,publisher,durpublisher"/>
+ </security>
+ <security match="topicjms.securedTopic">
+ <permission type="write" roles="publisher"/>
+ <permission type="read" roles="publisher"/>
+ </security>
- <mbean code="org.jboss.messaging.jms.server.destination.TopicService"
- name="jboss.messaging.destination:service=Topic,name=testTopic"
- xmbean-dd="xmdesc/Topic-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- <attribute name="SecurityConfig">
- <security>
- <role name="guest" read="true" write="true"/>
- <role name="publisher" read="true" write="true" create="false"/>
- <role name="durpublisher" read="true" write="true" create="true"/>
- </security>
- </attribute>
- </mbean>
+ <security match="topicjms.testDurableTopic">
+ <permission type="create" roles="durpublisher"/>
+ <permission type="read" roles="guest,publisher,durpublisher"/>
+ <permission type="write" roles="guest,publisher,durpublisher"/>
+ </security>
- <mbean code="org.jboss.messaging.jms.server.destination.TopicService"
- name="jboss.messaging.destination:service=Topic,name=securedTopic"
- xmbean-dd="xmdesc/Topic-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- <attribute name="SecurityConfig">
- <security>
- <role name="publisher" read="true" write="true" create="false"/>
- </security>
- </attribute>
- </mbean>
+ <security match="queuejms.testQueue">
+ <permission type="read" roles="guest,publisher"/>
+ <permission type="write" roles="guest,publisher"/>
+ </security>
+ <security match="queuejms.NoSuchQueue">
+ <permission type="read" roles="guest,publisher"/>
+ <permission type="write" roles="guest,publisher"/>
+ </security>
- <mbean code="org.jboss.messaging.jms.server.destination.QueueService"
- name="jboss.messaging.destination:service=Queue,name=testQueue"
- xmbean-dd="xmdesc/Queue-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- <attribute name="SecurityConfig">
- <security>
- <role name="guest" read="true" write="true"/>
- <role name="publisher" read="true" write="true" create="false"/>
- <role name="noacc" read="false" write="false" create="false"/>
- </security>
- </attribute>
- </mbean>
+ <security match="topicjms.NoSuchTopic">
+ <permission type="read" roles="guest,publisher"/>
+ <permission type="write" roles="guest,publisher"/>
+ </security>
- <mbean code="org.jboss.messaging.jms.server.destination.QueueService"
- name="jboss.messaging.destination:service=Queue,name=A"
- xmbean-dd="xmdesc/Queue-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- </mbean>
+ <security match="queuetempjms.*">
+ <permission type="create" roles="guest,def"/>
+ <permission type="read" roles="guest,def"/>
+ <permission type="write" roles="guest,def"/>
+ </security>
+ <security match="topictempjms.*">
+ <permission type="create" roles="guest,def"/>
+ <permission type="read" roles="guest,def"/>
+ <permission type="write" roles="guest,def"/>
+ </security>
- <!-- It's possible for indiviual queues and topics to use a specific queue for
- an expiry or DLQ -->
+ <!--this will catch any word i.e. queuejms.anything-->
+ <!--<security match="queuejms.^">
+ <permission type="read" roles="guest,publisher"/>
+ <permission type="write" roles="guest,publisher"/>
+ </security>-->
- <mbean code="org.jboss.messaging.jms.server.destination.QueueService"
- name="jboss.messaging.destination:service=Queue,name=PrivateDLQ"
- xmbean-dd="xmdesc/Queue-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- </mbean>
+ <!--this will catch any word i.e. queuejms.anything-->
+ <!--<security match="topicjms.^">
+ <permission type="read" roles="guest,publisher"/>
+ <permission type="write" roles="guest,publisher"/>
+ </security>-->
- <mbean code="org.jboss.messaging.jms.server.destination.QueueService"
- name="jboss.messaging.destination:service=Queue,name=PrivateExpiryQueue"
- xmbean-dd="xmdesc/Queue-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- </mbean>
+ <!--default security to catch all-->
+ <security match="*">
+ <permission type="create" roles="guest,def"/>
+ <permission type="read" roles="guest,def"/>
+ <permission type="write" roles="guest,def"/>
+ </security>
- <mbean code="org.jboss.messaging.jms.server.destination.QueueService"
- name="jboss.messaging.destination:service=Queue,name=QueueWithOwnDLQAndExpiryQueue"
- xmbean-dd="xmdesc/Queue-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- <attribute name="DLQ">
- jboss.messaging.destination:service=Queue,name=PrivateDLQ
- </attribute>
- <attribute name="ExpiryQueue">
- jboss.messaging.destination:service=Queue,name=PrivateExpiryQueue
- </attribute>
- </mbean>
+ <queue-settings match="queuejms.QueueWithOwnDLQAndExpiryQueue">
+ <dlq>PrivateDLQ</dlq>
+ <expiry-queue>queuejms.PrivateExpiryQueue</expiry-queue>
+ </queue-settings>
- <mbean code="org.jboss.messaging.jms.server.destination.TopicService"
- name="jboss.messaging.destination:service=Topic,name=TopicWithOwnDLQAndExpiryQueue"
- xmbean-dd="xmdesc/Topic-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- <attribute name="DLQ">
- jboss.messaging.destination:service=Queue,name=PrivateDLQ
- </attribute>
- <attribute name="ExpiryQueue">
- jboss.messaging.destination:service=Queue,name=PrivateExpiryQueue
- </attribute>
- </mbean>
+ <queue-settings match="topicjms.TopicWithOwnDLQAndExpiryQueue">
+ <dlq>PrivateDLQ</dlq>
+ <expiry-queue>queuejms.PrivateExpiryQueue</expiry-queue>
+ </queue-settings>
+ <queue-settings match="queuejms.QueueWithOwnRedeliveryDelay">
+ <redelivery-delay>5000</redelivery-delay>
+ </queue-settings>
- <mbean code="org.jboss.messaging.jms.server.destination.TopicService"
- name="jboss.messaging.destination:service=Topic,name=TopicWithOwnRedeliveryDelay"
- xmbean-dd="xmdesc/Topic-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- <attribute name="RedeliveryDelay">5000</attribute>
- </mbean>
+ <queue-settings match="topicjms.TopicWithOwnRedeliveryDelay">
+ <redelivery-delay>5000</redelivery-delay>
+ </queue-settings>
+ <queue-settings match="queuejms.testDistributedQueue">
+ <clustered>true</clustered>
+ </queue-settings>
- <mbean code="org.jboss.messaging.jms.server.destination.TopicService"
- name="jboss.messaging.destination:service=Topic,name=testDistributedTopic"
- xmbean-dd="xmdesc/Topic-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
- <attribute name="Clustered">true</attribute>
- </mbean>
-....
- </programlisting>
- </section>
- <!-- end conf.preconf.destinations -->
- <section id="conf.destination.queue">
- <title>Configuring queues</title>
- <section id="conf.destination.queue.attributes">
- <title>We now discuss the attributes of the Queue MBean</title>
- <section id="conf.destination.queue.attributes.name">
- <title>Name</title>
- <para>The name of the queue</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>
- <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.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>
- <section id="conf.destination.queue.attributes.security">
- <title>Destination Security Configuration</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 <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 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>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>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>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.queue.attributes.paging">
- <title>Destination paging parameters</title>
- <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>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>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>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>
- <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>
-
- long now = System.currentTimeMillis();
-
- Message msg = sess.createMessage();
-
- msg.setLongProperty(JBossMessage.JMS_JBOSS_SCHEDULED_DELIVERY_PROP_NAME,
- now + 1000 * 60 * 60 * 2);
-
- prod.send(msg);
-
- </programlisting>
- </section>
- <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>
- <section id="conf.destination.queue.attributes.clustered">
- <title>Clustered</title>
- <para>Clustered destinations must have this set to
- <literal>true</literal>.</para>
- </section>
- <section id="conf.destination.queue.attributes.messagecounter">
- <title>MessageCounter</title>
- <para>Each queue maintains a message counter.</para>
- </section>
- <section id="conf.destination.queue.attributes.messagecounterstats">
- <title>MessageCounterStatistics</title>
- <para>The statistics for the message counter</para>
- </section>
- <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>
- <section id="conf.destination.queue.attributes.consumercount">
- <title>ConsumerCount</title>
- <para>The number of consumers currently consuming from the
- queue.</para>
- </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>
- <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>
- <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>
- <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>
- <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>
- <section id="conf.destination.queue.operations.resetmessagecounter">
- <title>ResetMessageCounter</title>
- <para>Resets the message counter to zero.</para>
- </section>
- <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>
- <section id="conf.destination.queue.operations.listmessagecounterhistoryashtml">
- <title>ListMessageCounterHistoryAsHTML</title>
- <para>Lists the message counter history in an easy to display
- HTML format</para>
- </section>
- </section>
- </section>
- <section id="conf.destination.topics">
- <title>Configuring topics</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.jndiName">
- <title>JNDIName</title>
- <para>The JNDI name where the topic is bound</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.expiryqueue">
- <title>ExpiryQueue</title>
- <para>The Expiry queue used for this topic. Overrides any value
- set on the ServerPeer config</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.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>
- <section id="conf.destination.topic.attributes.security">
- <title>Destination Security Configuration</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 <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 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>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>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>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.paging">
- <title>Destination paging parameters</title>
- <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>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>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>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>
- <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.topic.attributes.createdprogrammatically">
- <title>CreatedProgrammatically</title>
- <para>Returns <literal>true</literal> if the topic was created
- programmatically</para>
- </section>
- <section id="conf.destination.topic.attributes.maxsize">
- <title>MaxSize</title>
- <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.clustered">
- <title>Clustered</title>
- <para>Clustered destinations must have this set to
- <literal>true</literal></para>
- </section>
- <section id="conf.destination.topic.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>
- <section id="conf.destination.topic.attributes.messagecounters">
- <title>MessageCounters</title>
- <para>Return a list of the message counters for the
- subscriptions of this topic.</para>
- </section>
- <section id="conf.destination.topic.attributes.allmessagecount">
- <title>AllMessageCount</title>
- <para>Return the total number of messages in all subscriptions
- of this topic.</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.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>
- <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>
+ <queue-settings match="topicjms.testDistributedTopic">
+ <clustered>true</clustered>
+ </queue-settings>
+
+ <queue-settings match="queuejms.testPerfQueue">
+ <clustered>false</clustered>
+ </queue-settings>
+
+ <!--default for catch all-->
+ <queue-settings match="*">
+ <clustered>false</clustered>
+ <dlq>DLQ</dlq>
+ <expiry-queue>queuejms.ExpiryQueue</expiry-queue>
+ <redelivery-delay>0</redelivery-delay>
+ <max-size>-1</max-size>
+ <distribution-policy-class>
+ org.jboss.messaging.core.server.impl.RoundRobinDistributionPolicy
+ </distribution-policy-class>
+ <message-counter-history-day-limit>10</message-counter-history-day-limit>
+ </queue-settings>
+
+ </deployment>
+ ]]>
+ </programlisting>
+ <para>The available configuration attributes are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>security</para>
+ <para>The securitysettings to use when clients access a destination.</para>
+ <itemizedlist>
+ <listitem>
+ <para>permission</para>
+ <para>This describes the permissions a user must have to perform certain tasks. The permission type
+ can be 'create','write' or 'read' and the roles are a comma seperated list of roles.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>queue-settings</para>
+ <para>These are the settings applied to a queue its creation.</para>
+ <itemizedlist>
+ <listitem>
+ <para>clustered</para>
+ <para>Whether or not this queue is clustered</para>
+ </listitem>
+ <listitem>
+ <para>dlq</para>
+ <para>The name of the Dead Letter Queue to use for this queue</para>
+ </listitem>
+ <listitem>
+ <para>expiry-queue</para>
+ <para>The name of the Expiry Queue to use for this queue</para>
+ </listitem>
+ <listitem>
+ <para>redelivery-delay</para>
+ <para>How long to wait, in milliseconds, before trying to redeliver a message.</para>
+ </listitem>
+ <listitem>
+ <para>max-size</para>
+ <para>The maximum number of messages a queue can hold before rejecting. -1 means unlimited which is
+ the default
+ </para>
+ </listitem>
+ <listitem>
+ <para>distribution-policy-class</para>
+ <para>The distribution policy class to use when multiple consumers are registered with a single queue.
+ A round robin policy is used by default.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
</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>
+ <section id="configuration.jms">
+ <title>jbm-jndi.xml</title>
+ <para>This configuration file is used to create destinations and Connection Factories and make them available in
+ JNDI. Note that this is the only configuration file that exposes JMS functionality.
+ </para>
+ <para>
+ A typical jbm-jndi.xml config looks like:
+ </para>
<programlisting>
-<mbean code="org.jboss.messaging.jms.server.connectionfactory.ConnectionFactory"
- name="jboss.messaging.connectionfactory:service=MyConnectionFactory"
- xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">
- <depends optional-attribute-name="ServerPeer">
- jboss.messaging:service=ServerPeer
- </depends>
- <depends optional-attribute-name="Connector">
- jboss.messaging:service=Connector,transport=bisocket
- </depends>
- <depends>jboss.messaging:service=PostOffice</depends>
+ <![CDATA[
+ <deployment>
- <attribute name="JNDIBindings">
- <bindings>
- <binding>/MyConnectionFactory</binding>
- <binding>/factories/cf</binding>
- </bindings>
- </attribute>
-
- <attribute name="ClientID">myClientID</attribute>
+ <connection-factory name="testConnectionFactory">
+ <entry name="testConnectionFactory"/>
+ </connection-factory>
- <attribute name="SupportsFailover">true</attribute>
-
- <attribute name="SupportsLoadBalancing">false</attribute>
-
- <attribute name="LoadBalancingFactory">org.acme.MyLoadBalancingFactory</attribute>
-
- <attribute name="PrefetchSize">1000</attribute>
+ <connection-factory name="ConnectionFactory">
+ <entry name="/ConnectionFactory"/>
+ <entry name="/XAConnectionFactory"/>
+ <entry name="java:/ConnectionFactory"/>
+ <entry name="java:/XAConnectionFactory"/>
+ </connection-factory>
- <attribute name="SlowConsumers">false</attribute>
-
- <attribute name="StrictTck">true</attribute>
+ <connection-factory name="ClusteredConnectionFactory">
+ <entry name="/ClusteredConnectionFactory"/>
+ <entry name="/ClusteredXAConnectionFactory"/>
+ <entry name="java:/ClusteredConnectionFactory"/>
+ <entry name="java:/ClusteredXAConnectionFactory"/>
+ <supports-failover>true</supports-failover>
+ <supports-load-balancing>true</supports-load-balancing>
+ </connection-factory>
- <attribute name="DefaultTempQueueFullSize">50000</attribute>
-
- <attribute name="DefaultTempQueuePageSize">1000</attribute>
-
- <attribute name="DefaultTempQueueDownCacheSize">1000</attribute>
-
- <attribute name="DupsOKBatchSize">10000</attribute>
- </mbean>
-
+ <connection-factory name="MyExampleConnectionFactory">
+ <entry name="/MyExampleConnectionFactory"/>
+ <entry name="/acme/MyExampleConnectionFactoryDupe"/>
+ <entry name="java:/xyz/CF1"/>
+ <entry name="java:/connectionfactories/acme/connection_factory"/>
+ <!-- You can specify the default Client ID to use for connections created
+ using this factory -->
+ <client-id>MyClientID</client-id>
+ <!-- PrefetchSize determines the maximum number of messages the client consumer
+ will buffer locally -->
+ <prefetch-size>150</prefetch-size>
+ <!-- The batch size to use when using the DUPS_OK_ACKNOWLEDGE acknowledgement mode -->
+ <dups-ok-batch-size>5000</dups-ok-batch-size>
+ <!-- Does this connection factory support automatic failover? -->
+ <supports-failover>false</supports-failover>
+ <!-- Does this connection factory support automatic client side load balancing? -->
+ <supports-load-balancing>false</supports-load-balancing>
+ <!-- The class name of the factory used to create the load balancing policy to
+ use on the client side -->
+ <load-balancing-factory>
+ org.jboss.messaging.jms.client.plugin.RoundRobinLoadBalancingFactory
+ </load-balancing-factory>
+ <!-- Whether we should be strict TCK compliant, i.e. how we deal with foreign messages,
+ defaults to false-->
+ <strict-tck>true</strict-tck>
- </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>
- <section id="conf.connectionfactory.attributes">
- <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.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>
- <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.tckstrictbehavior">
- <title>StrictTck</title>
- <para>Set this to true if you want strict JMS behaviour as
- required by the TCK.</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.disableremotingchecks">
- <title>DisableRemotingChecks</title>
- <para>By default, when deploying a connection factory, JBoss
- Messaging checks that the corresponding JBoss Remoting Connector
- has "sensible" values. JBoss Messaging is very sensitive to the
- values and for many of them there's rarely a good reason to change
- them. To disable such sanity checking set this to false. <warning>
- There is rarely a good reason to disable checking. Only do so if you are absolutely sure in what you are doing
- </warning></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.messaging.jms.client.plugin.LoadBalancingFactory</para>
- <para>The default value is
- org.jboss.messaging.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>Here is an example bisocket remoting configuration:
- <programlisting>
- <config>
- <invoker transport="bisocket">
-
- <!-- There should be no reason to change these parameters - warning!
- Changing them may stop JBoss Messaging working correctly -->
- <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
- <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
- <attribute name="dataType" isParam="true">jms</attribute>
- <attribute name="socket.check_connection" isParam="true">false</attribute>
- <attribute name="timeout" isParam="true">0</attribute>
- <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
- <attribute name="serverBindPort">4457</attribute>
- <attribute name="clientSocketClass" isParam="true">org.jboss.messaging.jms.client.remoting.ClientSocketWrapper</attribute>
- <attribute name="serverSocketClass" isParam="true">org.jboss.messaging.jms.server.remoting.ServerSocketWrapper</attribute>
- <attribute name="numberOfCallRetries" isParam="true">1</attribute>
- <attribute name="pingFrequency" isParam="true">214748364</attribute>
- <attribute name="pingWindowFactor" isParam="true">10</attribute>
- <attribute name="onewayThreadPool">org.jboss.messaging.jms.server.remoting.DirectThreadPool</attribute>
-
- <!-- Periodicity of client pings. Server window by default is twice this figure -->
- <attribute name="clientLeasePeriod" isParam="true">10000</attribute>
+ <!-- This is the window size in number of messages to use when using producer
+ window based flow control -->
+ <producer-window-size>1000</producer-window-size>
- <!-- Number of seconds to wait for a connection in the client pool to become free -->
- <attribute name="numberOfRetries" isParam="true">10</attribute>
+ <!-- This is the maximum producer send rate that will be applied when using
+ rate based producer flow control -->
+ <producer-max-rate>100</producer-max-rate>
- <!-- Max Number of connections in client pool. This should be significantly higher than
- the max number of sessions/consumers you expect -->
- <attribute name="clientMaxPoolSize" isParam="true">200</attribute>
-
- <!-- Use these parameters to specify values for binding and connecting control connections to
- work with your firewall/NAT configuration
- <attribute name="secondaryBindPort">xyz</attribute>
- <attribute name="secondaryConnectPort">abc</attribute>
- -->
-
- </invoker>
- <handlers>
- <handler subsystem="JMS">org.jboss.messaging.jms.server.remoting.JMSServerInvocationHandler</handler>
- </handlers>
- </config>
- </programlisting></para>
- <para>Please note that some of the attributes should not be changed
- unless you know exactly what you are doing. We will discuss the
- attributes that you may have a good reason to change:</para>
- <para><itemizedlist>
- <listitem>
- clientLeasePeriod - Clients periodically send heartbeats to the server to tell the server they are still alive. If the server does not receive a heartbeat after a certain time it will close down the connection and remove all resources on the server corresponding to the client's session. The clientLeasePeriod determines the period of heartbeats. The server will (by default) close a client if it does not receive a heartbeat in 2 * clientLeasePeriod ms. The actual factor gets automatically resized according to system load. The value is in milliseconds. The defaut value is 10000 ms.
- </listitem>
- <listitem>
- numberOfRetries - This effectively corresponds to the number of seconds JBoss Remoting will block on the client connection pool waiting for a connection to become free. If you have a very large number of sessions concurrently accessing the server from a client and you are experiencing issues due to not being able to obtain connections from the pool, you may want to consider increasing this value.
- </listitem>
- <listitem>
- clientMaxPoolSize - JBoss Remoting maintains a client side pool of TCP connections on which to service requests. If you have a very large number of sessions concurrently accessing the server from a client and you are experiencing issues due to not being able to obtain connections from the pool in a timely manner, you may want to consider increasing this value.
- </listitem>
- <listitem>
- secondaryBindPort - The bisocket transport uses control connections to pass control messages between server and client. If you want to work behind a firewall you may want to specify a particular value for this according to your firewall configuration. This is the address the secondary ServerSocket binds to
- </listitem>
- <listitem>
- secondaryConnectPort - This is the port the client uses to connect. You may want to specify this to allow clients to work with NAT routers.
- </listitem>
- <listitem>
- maxPoolSize - This is the number of threads used on the server side to service requests.
- </listitem>
- </itemizedlist></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>
- There is rarely a good reason to change values in the the bisocket or sslbisocket connector configuration apart from clientLeasePeriod, clientMaxPoolSize, maxRetries, numberOfRetries, secondaryBindPort or secondaryConnectPort. Changing them can cause JBoss Messaging to stop functioning correctly.
- </warning>
+ </connection-factory>
+
+ <queue name="DLQ">
+ <entry name="/queue/DLQ"/>
+ </queue>
+ <queue name="ExpiryQueue">
+ <entry name="/queue/ExpiryQueue"/>
+ </queue>
+ <topic name="testTopic">
+ <entry name="/topic/testTopic"/>
+ </topic>
+ <topic name="securedTopic">
+ <entry name="/topic/securedTopic"/>
+ </topic>
+ <topic name="testDurableTopic">
+ <entry name="/topic/testDurableTopic"/>
+ </topic>
+ <queue name="testQueue">
+ <entry name="/queue/testQueue"/>
+ </queue>
+ <queue name="testPerfQueue">
+ <entry name="/queue/testPerfQueue"/>
+ </queue>
+ <queue name="A">
+ <entry name="/queue/A"/>
+ </queue>
+ <queue name="B">
+ <entry name="/queue/B"/>
+ </queue>
+ <queue name="C">
+ <entry name="/queue/C"/>
+ </queue>
+ <queue name="D">
+ <entry name="/queue/D"/>
+ </queue>
+ <queue name="ex">
+ <entry name="/queue/ex"/>
+ </queue>
+ <queue name="PrivateDLQ">
+ <entry name="/queue/PrivateDLQ"/>
+ </queue>
+ <queue name="PrivateExpiryQueue">
+ <entry name="/queue/PrivateExpiryQueue"/>
+ </queue>
+ <queue name="QueueWithOwnDLQAndExpiryQueue">
+ <entry name="/queue/QueueWithOwnDLQAndExpiryQueue"/>
+ </queue>
+ <topic name="TopicWithOwnDLQAndExpiryQueue">
+ <entry name="/topic/QueueWithOwnDLQAndExpiryQueue"/>
+ </topic>
+ <queue name="QueueWithOwnRedeliveryDelay">
+ <entry name="/queue/QueueWithOwnRedeliveryDelay"/>
+ </queue>
+ <topic name="TopicWithOwnRedeliveryDelay">
+ <entry name="/queue/TopicWithOwnRedeliveryDelay"/>
+ </topic>
+ <queue name="testDistributedQueue">
+ <entry name="/topic/testDistributedQueue"/>
+ </queue>
+ <topic name="testDistributedTopic">
+ <entry name="/topic/testDistributedTopic"/>
+ </topic>
+
+</deployment>
+ ]]>
+ </programlisting>
+ <para>The available configuration attributes are:</para>
+ <itemizedlist>
+ <listitem>
+ <para>connection-factory</para>
+ <para>The connection factory to create with a unique name</para>
+ <itemizedlist>
+ <listitem>
+ <para>entry</para>
+ <para>The name to store the Connection Factory object in JNDI with.
+ Multiple JNDI entries can be added.</para>
+ </listitem>
+ <listitem>
+ <para>client-id</para>
+ <para>The client id for connections created using this Connection Factory</para>
+ </listitem>
+ <listitem>
+ <para>prefetch-size</para>
+ <para>The maximum number of messages a consumer can buffer locally</para>
+ </listitem>
+ <listitem>
+ <para>dups-ok-batch-size</para>
+ <para>The number of acks to batch up when DUPS_OK_ACKNOWLEDGE acknowledgement mode is used</para>
+ </listitem>
+ <listitem>
+ <para>supports-failover</para>
+ <para>Does the Connection Factory support failover, currently disabled.</para>
+ </listitem>
+ <listitem>
+ <para>supports-load-balancing</para>
+ <para>Does the Connection Factory support load balancing, currently disabled</para>
+ </listitem>
+ <listitem>
+ <para>load-balancing-factory</para>
+ <para>The class to use for creating the load balancing class, currently not used.</para>
+ </listitem>
+ <listitem>
+ <para>strict-tck</para>
+ <para>Whether strict tck shoul dbe adhered to</para>
+ </listitem>
+ <listitem>
+ <para>producer-window-size</para>
+ <para>The window size when producer window based flow control is enabled.</para>
+ </listitem>
+ <listitem>
+ <para>producer-max-rate</para>
+ <para>The max rate when producer rate based flow control is enabled.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>queue</para>
+ <para>The queue to create with a unique name.</para>
+ <itemizedlist>
+ <listitem>
+ <para>entry</para>
+ <para>The name to store the Connection Factory object in JNDI with.
+ Multiple JNDI entries can be added.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>topic</para>
+ <para>The queue to create with a unique name.</para>
+ <itemizedlist>
+ <listitem>
+ <para>entry</para>
+ <para>The name to store the Connection Factory object in JNDI with.
+ Multiple JNDI entries can be added.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
</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>If you are using a newer version of JBM in an older version of
- JBAS then the example bindings in the AS distribution may well be out of
- date. It is therefore imperative that the relevant sections are
- overwritten with the remoting configuration from the JBM
- distribution.</para>
- <para>See the chapter on installation for a description of how to set-up
- the service binding manager for JBoss Messaging</para>
- </section>
- <!-- End conf.callback -->
</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/installation.xml
===================================================================
--- trunk/docs/userguide/en/modules/installation.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/userguide/en/modules/installation.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -1,808 +1,161 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="installation">
<title>JBoss Messaging Installation</title>
- <para>This section describes procedures on how to install JBoss Messaging
- into JBoss AS. At the end of this procedure, you will create a JBoss
- Messaging configuration that will start a clustered or non-clustered
- messaging server.</para>
- <para>By default, JBoss AS 4 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
- <filename>jboss-messaging.sar</filename>
- 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>
- <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>
- <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>
- </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>
- <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>
- <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>
- <programlisting>
- cd util
- ant -f release-admin.xml
- </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 want 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>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
- <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>
- </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>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>
- </listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para>Ensure the <literal>ServerPeerID</literal> MBean
- attribute value in messaging-service.xml is unique for each
- node. The <literal>ServerPeerID</literal> value must be a valid
- integer. Every node MUST have a unique id, including those just
- connected by message bridges.</para>
- <para>
- <warning>Each node must have a unique
- <literal>ServerPeerID</literal> irrespective of whether you
- are using clustering.</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>
- <para>Specify the desired port rage (e.g. ports-01,
- ports-02... etc)</para>
- </listitem>
- <listitem>
- <para>Look at
- $JBOSS_HOME/docs/examples/binding-manager/sample-bindings.xml.
- Here is an example:</para>
- <programlisting>
- <service-config name="jboss.messaging:service=Connector,transport=bisocket"
- delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
- <delegate-config>
- <attribute name="Configuration"><![CDATA[
- <config>
- <invoker transport="bisocket">
-
- <!-- There should be no reason to change these parameters - warning!
- Changing them may stop JBoss Messaging working correctly -->
- <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
- <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
- <attribute name="dataType" isParam="true">jms</attribute>
- <attribute name="socket.check_connection" isParam="true">false</attribute>
- <attribute name="timeout" isParam="true">0</attribute>
- <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
- <attribute name="serverBindPort">4657</attribute>
- <attribute name="clientSocketClass" isParam="true">org.jboss.messaging.jms.client.remoting.ClientSocketWrapper</attribute>
- <attribute name="serverSocketClass" isParam="true">org.jboss.messaging.jms.server.remoting.ServerSocketWrapper</attribute>
- <attribute name="numberOfCallRetries" isParam="true">1</attribute>
- <attribute name="pingFrequency" isParam="true">214748364</attribute>
- <attribute name="pingWindowFactor" isParam="true">10</attribute>
- <attribute name="onewayThreadPool">org.jboss.messaging.jms.server.remoting.DirectThreadPool</attribute>
-
- <!-- Periodicity of client pings. Server window by default is twice this figure -->
- <attribute name="clientLeasePeriod" isParam="true">10000</attribute>
+ <para>This section describes procedures on how to install JBoss Messaging both standalone and within JBoss AS 5
+ </para>
- <!-- Number of seconds to wait for a connection in the client pool to become free -->
- <attribute name="numberOfRetries" isParam="true">10</attribute>
-
- <!-- Max Number of connections in client pool. This should be significantly higher than
- the max number of sessions/consumers you expect -->
- <attribute name="clientMaxPoolSize" isParam="true">200</attribute>
-
- <!-- Use these parameters to specify values for binding and connecting control connections to
- work with your firewall/NAT configuration
- <attribute name="secondaryBindPort">xyz</attribute>
- <attribute name="secondaryConnectPort">abc</attribute>
- -->
-
- </invoker>
- <handlers>
- <handler subsystem="JMS">org.jboss.messaging.jms.server.remoting.JMSServerInvocationHandler</handler>
- </handlers>
- </config>
- ]]></attribute>
- </delegate-config>
- <binding port="4657"/>
- </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 may be out of date and you will need to copy
- the config from <literal>remoting-bisocket-service.xml.
- DO NOT just copy and paste from the above example - copy
- it from the JBoss Messaging
- distribution.</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>
- </listitem>
- <listitem>That's it</listitem>
- </itemizedlist>
- </section>
- <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>
- <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>
- </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>
-
- <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>
-<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule" flag = "required" >
- <module-option name = "unauthenticatedIdentity">guest</module-option>
- <module-option name = "usersProperties">props/messaging-users.properties</module-option>
- <module-option name = "rolesProperties">props/messaging-roles.properties</module-option>
-</login-module>
-</authentication>
-</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>
-
- <programlisting>
-# messaging-roles.properties
-# Add roles as you like
-# user=role1,role2,...
-#
-guest=guest
- </programlisting>
-
- <programlisting>
-# messaging-users.properties
-
-# Add users as you like
-# user=password
-#
-guest=guest
- </programlisting>
-
- </listitem>
- <listitem>
- <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>
- </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>
- </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>
- <itemizedlist>
- <listitem>
- <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>
- </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>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>
- </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>
- irrespective of whether you are using clustering.
- </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>
- <para>Specify the desired port rage (e.g. ports-01,
- ports-02... etc)</para>
- </listitem>
- <listitem>
- <para>Look at
- $JBOSS_HOME/docs/examples/binding-manager/sample-bindings.xml.
- On each port range, JBoss Remoting configuration should
- look like:</para>
- <programlisting>
- <service-config name="jboss.messaging:service=Connector,transport=bisocket"
- delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
- <delegate-config>
- <attribute name="Configuration"><![CDATA[
- <config>
- <invoker transport="bisocket">
-
- <!-- There should be no reason to change these parameters - warning!
- Changing them may stop JBoss Messaging working correctly -->
- <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
- <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
- <attribute name="dataType" isParam="true">jms</attribute>
- <attribute name="socket.check_connection" isParam="true">false</attribute>
- <attribute name="timeout" isParam="true">0</attribute>
- <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
- <attribute name="serverBindPort">4657</attribute>
- <attribute name="clientSocketClass" isParam="true">org.jboss.messaging.jms.client.remoting.ClientSocketWrapper</attribute>
- <attribute name="serverSocketClass" isParam="true">org.jboss.messaging.jms.server.remoting.ServerSocketWrapper</attribute>
- <attribute name="numberOfCallRetries" isParam="true">1</attribute>
- <attribute name="pingFrequency" isParam="true">214748364</attribute>
- <attribute name="pingWindowFactor" isParam="true">10</attribute>
- <attribute name="onewayThreadPool">org.jboss.messaging.jms.server.remoting.DirectThreadPool</attribute>
-
- <!-- Periodicity of client pings. Server window by default is twice this figure -->
- <attribute name="clientLeasePeriod" isParam="true">10000</attribute>
-
- <!-- Number of seconds to wait for a connection in the client pool to become free -->
- <attribute name="numberOfRetries" isParam="true">10</attribute>
-
- <!-- Max Number of connections in client pool. This should be significantly higher than
- the max number of sessions/consumers you expect -->
- <attribute name="clientMaxPoolSize" isParam="true">200</attribute>
-
- <!-- Use these parameters to specify values for binding and connecting control connections to
- work with your firewall/NAT configuration
- <attribute name="secondaryBindPort">xyz</attribute>
- <attribute name="secondaryConnectPort">abc</attribute>
- -->
-
- </invoker>
- <handlers>
- <handler subsystem="JMS">org.jboss.messaging.jms.server.remoting.JMSServerInvocationHandler</handler>
- </handlers>
- </config>
- ]]></attribute>
- </delegate-config>
- <binding port="4657"/>
- </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 may be out of date and you will need to copy the config from
- <literal>remoting-bisocket-service.xml. DO NOT just
- copy and paste from the above example - copy it from
- the JBoss Messaging distribution.</literal>
-
- <literal />
-
- <literal />
-
- <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>
- </listitem>
- <listitem>
- That's it
- </listitem>
- </itemizedlist>
- </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>
- </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>The
- version is JBoss Remoting 2.2.2.SP1-brew. 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>
- <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/conf/standardjboss.xml</literal> 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>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 JBoss MQ.</para>
- </listitem>
- <listitem>
- <para>Edit $JBOSS_CONFIG/conf/jboss-service.xml and remove the
- reference to JBoss MQ on JSR-77 Management Bean:</para>
- <programlisting>
- <!-- ==================================================================== -->
- <!-- JSR-77 Single JBoss Server Management Domain -->
- <!-- ==================================================================== -->
- <mbean code="org.jboss.management.j2ee.LocalJBossServerDomain"
-
- ... Remove this line ...
- <attribute name="JMSService">jboss.mq:service=DestinationManager</attribute>
- </programlisting>
- </listitem>
- <listitem>
- <para>Change
- <literal>$JBOSS_CONFIG/conf/login-config.xml</literal> and
- remove jboss-mq security policies</para>
- <programlisting>
-### Remove these lines:
-
-<!-- Security domain for JBossMQ -->
-<application-policy name = "jbossmq">
- <authentication>
- <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
- flag = "required">
- <module-option name = "unauthenticatedIdentity">guest</module-option>
- <module-option name = "dsJndiName">java:/DefaultDS</module-option>
- <module-option name = "principalsQuery">
- SELECT PASSWD FROM JMS_USERS WHERE USERID=?</module-option>
- <module-option name = "rolesQuery">
- SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=?</module-option>
- </login-module>
- </authentication>
-</application-policy>
-
-<!-- Security domain for JBossMQ when using file-state-service.xml
-<application-policy name = "jbossmq">
- <authentication>
- <login-module code = "org.jboss.mq.sm.file.DynamicLoginModule"
- flag = "required">
- <module-option name = "unauthenticatedIdentity">guest</module-option>
- <module-option name = "sm.objectname">jboss.mq:service=StateManager</module-option>
- </login-module>
- </authentication>
-</application-policy>
--->
-
- </programlisting>
- </listitem>
- </itemizedlist>
- </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>
+ <section id="installation.standalone">
+ <title>Installing JBoss Messaging standalone</title>
+ <para>After downloading the distribution unzip it into your chosen directory. At this point it should be possible
+ to run straight of the box, the following describes the directory structure that should be seen
+ </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>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>
- <programlisting>
-....
-13:19:14,914 WARN [JDBCPersistenceManager]
-
-JBoss Messaging Warning: DataSource connection transaction isolation should be READ_COMMITTED,
-but it is currently NONE.
- Using an isolation level less strict than READ_COMMITTED may lead to
-data consistency problems.
- Using an isolation level more strict than READ_COMMITTED may lead to
-deadlock.
-
-13:19:15,166 INFO [ServerPeer] JBoss Messaging 1.4.0.GA server [0] started
-13:19:15,411 INFO [ConnectionFactory] Connector bisocket://127.0.0.1:4457 has leasing enabled
-, lease period 10000 milliseconds
-13:19:15,412 INFO [ConnectionFactory] [/ConnectionFactory, /XAConnectionFactory, java:/Connec
-tionFactory, java:/XAConnectionFactory] started
-13:19:15,412 WARN [ConnectionFactoryJNDIMapper] supportsFailover attribute is true on connect
-ion factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but
-post office is non clustered. So connection factory will *not* support failover
-13:19:15,413 WARN [ConnectionFactoryJNDIMapper] supportsLoadBalancing attribute is true on co
-nnection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory
-but post office is non clustered. So connection factory will *not* support load balanc
-ing
-13:19:15,449 INFO [ConnectionFactory] Connector bisocket://127.0.0.1:4457 has leasing enabled
-, lease period 10000 milliseconds
-13:19:15,449 INFO [ConnectionFactory] [/ClusteredConnectionFactory, /ClusteredXAConnectionFac
-tory, java:/ClusteredConnectionFactory, java:/ClusteredXAConnectionFactory] started
-13:19:15,468 INFO [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, d
-ownCacheSize=2000
-13:19:15,474 INFO [QueueService] Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize
-=2000, downCacheSize=2000
-13:19:15,476 INFO [TopicService] Topic[/topic/testTopic] started, fullSize=200000, pageSize=2
-000, downCacheSize=2000
-13:19:15,478 INFO [TopicService] Topic[/topic/securedTopic] started, fullSize=200000, pageSiz
-e=2000, downCacheSize=2000
-13:19:15,479 INFO [TopicService] Topic[/topic/testDurableTopic] started, fullSize=200000, pag
-eSize=2000, downCacheSize=2000
-13:19:15,482 INFO [QueueService] Queue[/queue/testQueue] started, fullSize=200000, pageSize=2
-000, downCacheSize=2000
-13:19:15,483 INFO [QueueService] Queue[/queue/A] started, fullSize=200000, pageSize=2000, dow
-nCacheSize=2000
-13:19:15,485 INFO [QueueService] Queue[/queue/B] started, fullSize=200000, pageSize=2000, dow
-nCacheSize=2000
-13:19:15,487 INFO [QueueService] Queue[/queue/C] started, fullSize=200000, pageSize=2000, dow
-nCacheSize=2000
-13:19:15,489 INFO [QueueService] Queue[/queue/D] started, fullSize=200000, pageSize=2000, dow
-nCacheSize=2000
-13:19:15,490 INFO [QueueService] Queue[/queue/ex] started, fullSize=200000, pageSize=2000, do
-wnCacheSize=2000
-13:19:15,501 INFO [QueueService] Queue[/queue/PrivateDLQ] started, fullSize=200000, pageSize=
-2000, downCacheSize=2000
-13:19:15,503 INFO [QueueService] Queue[/queue/PrivateExpiryQueue] started, fullSize=200000, p
-ageSize=2000, downCacheSize=2000
-13:19:15,507 INFO [QueueService] Queue[/queue/QueueWithOwnDLQAndExpiryQueue] started, fullSiz
-e=200000, pageSize=2000, downCacheSize=2000
-13:19:15,508 INFO [TopicService] Topic[/topic/TopicWithOwnDLQAndExpiryQueue] started, fullSiz
-e=200000, pageSize=2000, downCacheSize=2000
-13:19:15,511 INFO [QueueService] Queue[/queue/QueueWithOwnRedeliveryDelay] started, fullSize=
-200000, pageSize=2000, downCacheSize=2000
-13:19:15,512 INFO [TopicService] Topic[/topic/TopicWithOwnRedeliveryDelay] started, fullSize=
-200000, pageSize=2000, downCacheSize=2000
-13:19:15,514 INFO [QueueService] Queue[/queue/testDistributedQueue] started, fullSize=200000,
-pageSize=2000, downCacheSize=2000
-13:19:15,519 INFO [TopicService] Topic[/topic/testDistributedTopic] started, fullSize=200000,
-pageSize=2000, downCacheSize=2000
-13:19:15,809 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:servic
-e=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
-13:19:15,834 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-consol
-e.war/
-13:19:16,322 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
-13:19:16,342 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
-13:19:16,480 INFO [Server] JBoss (MX MicroKernel) [4.2.0.GA (build: SVNTag=JBoss_4_2_0_GA dat
-e=200705111440)] Started in 19s:359ms
-
- </programlisting>
- <note>
- The warning message
- <literal>"DataSource connection transaction isolation should be
- READ_COMMITTED, but it is currently NONE"</literal>
- is there to remind you that by default JBossAS ships with Hypersonic, an in-memory Java-based database engine, which is apropriate for demo purposes, but not for heavy load production environments. 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.
- </note>
- <warning>
- Before using Messaging in production, you
- <emphasis>must</emphasis>
- configure the Messaging instance to use an enterprise-class database backend such as Oracle, Sybase, PostgreSQL, MS SQL or MySQL, otherwise you risk losing your data. See
- <xref linkend="conf.changingds" />
- for details about replacing Hypersonic.
- </warning>
- </section>
- <section id="inst.validation">
- <title>Installation Validation</title>
- <para>The release bundle contains a series of examples that should run
- "out of the box" and could be used to validate a new installation. Such
- an example sends a persistent JMS message to a queue called
- <literal>queue/testQueue</literal>.</para>
- <para>To run the example and validate the installation, open an new
- command line window and set the <literal>JBOSS_HOME</literal>
- environment variable to point to the JBoss AS 4.x installation you've
- just installed Messaging on. Navigate to the folder where you extracted
- the release 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>
- <programlisting>
-
-setenv JBOSS_HOME=<your_JBoss_installation>
-cd .../examples/queue
-$ant
-
- </programlisting>
- <para>A successfull execution log output looks similar to:</para>
- <programlisting>
-[tim at Vigor14 queue]$ ant
-Buildfile: build.xml
-
-identify:
- [echo] ###########################################################################
- [echo] # Running the QUEUE example #
- [echo] ###########################################################################
- [echo] The queue: testQueue
- [echo] The client jar: ../../../output/lib/jboss-messaging-client.jar
-
-sanity-check:
-
-init:
- [mkdir] Created dir: /home/tim/dev/jboss-messaging/trunk/docs/examples/queue/output/classe
-s
- [mkdir] Created dir: /home/tim/dev/jboss-messaging/trunk/docs/examples/common/output/class
-es
-
-compile:
- [javac] Compiling 5 source files to /home/tim/dev/jboss-messaging/trunk/docs/examples/comm
-on/output/classes
- [javac] Compiling 1 source file to /home/tim/dev/jboss-messaging/trunk/docs/examples/queue
-/output/classes
-
-run:
- [java] Queue /queue/testQueue exists
- [java] The message was successfully sent to the testQueue queue
- [java] Received message: Hello!
- [java] The example connected to JBoss Messaging version 1.4.0.GA (1.4)
-
- [java] #####################
- [java] ### SUCCESS! ###
- [java] #####################
-
-BUILD SUCCESSFUL
-Total time: 5 seconds
-[tim at Vigor14 queue]$
-
-</programlisting>
- <para>It is recommended to run <literal>all</literal> validation
- examples available in the <filename>example</filename> directory
- (<filename>queue</filename>, <filename>topic</filename>,
- <filename>mdb</filename>, <filename>stateless</filename>, etc.). In
- <xref 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>
+ |-- bin
+ |-- config
+ |-- docs
+ | |-- api
+ | |-- examples
+ | `-- userguide
+ `-- lib
+ </programlisting>
<itemizedlist>
<listitem>
- <para><note>
- JBoss Messaging 1.4.0 requires a patched version of jboss-remoting.jar. The version is JBoss Remoting 2.2.2.SP1-brew. 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>
+ <para>bin</para>
+ <para>This contains the binaries and scripts needed to run JBM.</para>
</listitem>
<listitem>
- <para>jboss-messaging-client.jar - This is available in the
- messaging distribution</para>
+ <para>config</para>
+ <para>This contains configuration files needed to configure JBM. Refer to the configuration chapter for
+ details on how to do this.
+ </para>
</listitem>
<listitem>
- <para>jbossall-client.jar - This is available in your
- $JBOSS_HOME/client directory</para>
+ <para>docs</para>
+ <para>This contains this user guide, the JBM Javadocs and a set of examples. Refer to the 'running examples'
+ chapter for details on how to run them.
+ </para>
</listitem>
<listitem>
- <para>$JBOSS_HOME/server/<SERVER_NAME>/deploy/jboss-aop.deployer/jboss-aop.jar</para>
- <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>
+ <para>lib</para>
+ <para>This contains jars needed to run JBM.
+ </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>
+ <para>To run JBM, open up a shell or command prompt and navigate into the 'bin' directory. Then execute './run.sh'
+ (or 'run.bat' on windows) and you should see the following output</para>
+ <programlisting>
+ java -Xmx512M -Dorg.jboss.logging.Logger.pluginClass=org.jboss.messaging.core
+ .logging.JBMLoggerPlugin -Djava.library.path=. -classpath ../lib/xercesImpl.j
+ ar:../lib/trove.jar:../lib/slf4j-log4j12.jar:../lib/slf4j-api-1.4.3.jar:../li
+ b/mina-core-2.0.0-M2-20080418.144850.jar:../lib/log4j.jar:../lib/jnpserver.ja
+ r:../lib/jgroups.jar:../lib/jboss-xml-binding.jar:../lib/jbossts-common.jar:.
+ ./lib/jboss-transaction-spi.jar:../lib/jbosssx-client.jar:../lib/jboss-securi
+ ty-spi.jar:../lib/jboss-messaging.jar:../lib/jboss-messaging-client.jar:../li
+ b/jboss-kernel.jar:../lib/jbossjta.jar:../lib/jbossjta-integration.jar:../lib
+ /jboss-javaee.jar:../lib/jboss-jaspi-api.jar:../lib/jboss-dependency.jar:../l
+ ib/jboss-container.jar:../lib/jboss-common-logging-spi.jar:../lib/jboss-commo
+ n-core.jar:../lib/jboss-aop-mc-int.jar:../lib/jboss-aop-jdk50.jar:../lib/java
+ ssist.jar:../lib/concurrent.jar:../lib/commons-logging.jar:../config/ org.jbo
+ ss.jms.server.microcontainer.JBMBootstrapServer jbm-standalone-beans.xml
+ 10:25:57,225 INFO @main [JournalStorageManager] Directory /home/andy/jbm-tes
+ t/data/bindings does not already exists
+ 10:25:57,226 INFO @main [JournalStorageManager] Creating it
+ 10:25:57,270 INFO @main [JournalStorageManager] Directory /home/andy/jbm-tes
+ t/data/journal does not already exists
+ 10:25:57,271 INFO @main [JournalStorageManager] Creating it
+ 10:25:57,276 INFO @main [JournalStorageManager] AIO loaded successfully
+ 10:25:57,689 INFO @main [MinaService] Registering:tcp://localhost:5400
+ 10:25:57,707 INFO @main [FileDeploymentManager] Deploying org.jboss.messagin
+ g.core.deployers.impl.SecurityDeployer at fe0fd9 with urlfile:/home/andy/project
+ s/jBossMessaging/build/messaging-2.0.0.alpha1/config/queues.xml
+ 10:25:57,758 INFO @main [XmlDeployer] deploying topicjms.testTopic
+ 10:25:57,761 INFO @main [XmlDeployer] deploying topicjms.securedTopic
+ 10:25:57,761 INFO @main [XmlDeployer] deploying topicjms.testDurableTopic
+ 10:25:57,762 INFO @main [XmlDeployer] deploying queuejms.testQueue
+ 10:25:57,762 INFO @main [XmlDeployer] deploying queuejms.NoSuchQueue
+ 10:25:57,763 INFO @main [XmlDeployer] deploying topicjms.NoSuchTopic
+ 10:25:57,763 INFO @main [XmlDeployer] deploying queuetempjms.*
+ 10:25:57,764 INFO @main [XmlDeployer] deploying topictempjms.*
+ 10:25:57,764 INFO @main [XmlDeployer] deploying *
+ 10:25:57,765 INFO @main [FileDeploymentManager] Deploying org.jboss.messagin
+ g.core.deployers.impl.QueueSettingsDeployer at 1220b36 with urlfile:/home/andy/p
+ rojects/jBossMessaging/build/messaging-2.0.0.alpha1/config/queues.xml
+ 10:25:57,783 INFO @main [XmlDeployer] deploying queuejms.QueueWithOwnDLQAndE
+ xpiryQueue
+ 10:25:57,784 INFO @main [XmlDeployer] deploying topicjms.TopicWithOwnDLQAndE
+ xpiryQueue
+ 10:25:57,784 INFO @main [XmlDeployer] deploying queuejms.QueueWithOwnRedeliv
+ eryDelay
+ 10:25:57,784 INFO @main [XmlDeployer] deploying topicjms.TopicWithOwnRedeliv
+ eryDelay
+ 10:25:57,785 INFO @main [XmlDeployer] deploying queuejms.testDistributedQueu
+ e
+ 10:25:57,785 INFO @main [XmlDeployer] deploying topicjms.testDistributedTopi
+ c
+ 10:25:57,785 INFO @main [XmlDeployer] deploying queuejms.testPerfQueue
+ 10:25:57,785 INFO @main [XmlDeployer] deploying *
+ 10:26:02,824 INFO @main [FileDeploymentManager] Deploying org.jboss.messagin
+ g.core.deployers.impl.SecurityManagerDeployer at 1a1ff9 with urlfile:/home/andy/
+ projects/jBossMessaging/build/messaging-2.0.0.alpha1/config/jbm-security.xml
+ 10:26:02,831 INFO @main [XmlDeployer] deploying guest
+ 10:26:02,991 INFO @main [FileDeploymentManager] Deploying org.jboss.messagin
+ g.jms.server.impl.JMSServerDeployer at d6c07 with urlfile:/home/andy/projects/jB
+ ossMessaging/build/messaging-2.0.0.alpha1/config/jbm-jndi.xml
+ 10:26:03,005 INFO @main [XmlDeployer] deploying DLQ
+ 10:26:03,035 INFO @main [XmlDeployer] deploying ExpiryQueue
+ 10:26:03,038 INFO @main [XmlDeployer] deploying testQueue
+ 10:26:03,044 INFO @main [XmlDeployer] deploying testPerfQueue
+ 10:26:03,046 INFO @main [XmlDeployer] deploying A
+ 10:26:03,048 INFO @main [XmlDeployer] deploying B
+ 10:26:03,050 INFO @main [XmlDeployer] deploying C
+ 10:26:03,051 INFO @main [XmlDeployer] deploying D
+ 10:26:03,072 INFO @main [XmlDeployer] deploying ex
+ 10:26:03,075 INFO @main [XmlDeployer] deploying PrivateDLQ
+ 10:26:03,077 INFO @main [XmlDeployer] deploying PrivateExpiryQueue
+ 10:26:03,078 INFO @main [XmlDeployer] deploying QueueWithOwnDLQAndExpiryQueu
+ e
+ 10:26:03,080 INFO @main [XmlDeployer] deploying QueueWithOwnRedeliveryDelay
+ 10:26:03,081 INFO @main [XmlDeployer] deploying testDistributedQueue
+ 10:26:03,083 INFO @main [XmlDeployer] deploying testTopic
+ 10:26:03,086 INFO @main [XmlDeployer] deploying securedTopic
+ 10:26:03,087 INFO @main [XmlDeployer] deploying testDurableTopic
+ 10:26:03,088 INFO @main [XmlDeployer] deploying TopicWithOwnDLQAndExpiryQueu
+ e
+ 10:26:03,089 INFO @main [XmlDeployer] deploying TopicWithOwnRedeliveryDelay
+ 10:26:03,090 INFO @main [XmlDeployer] deploying testDistributedTopic
+ 10:26:03,091 INFO @main [XmlDeployer] deploying testConnectionFactory
+ 10:26:03,091 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,101 INFO @main [XmlDeployer] deploying ConnectionFactory
+ 10:26:03,101 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,102 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,103 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,103 WARN @main [JMSServerManagerImpl] Binding for java:/ConnectionF
+ actory already exists
+ 10:26:03,103 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,104 WARN @main [JMSServerManagerImpl] Binding for java:/XAConnectio
+ nFactory already exists
+ 10:26:03,104 INFO @main [XmlDeployer] deploying ClusteredConnectionFactory
+ 10:26:03,104 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,105 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,106 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,106 WARN @main [JMSServerManagerImpl] Binding for java:/ClusteredCo
+ nnectionFactory already exists
+ 10:26:03,106 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,106 WARN @main [JMSServerManagerImpl] Binding for java:/ClusteredXA
+ ConnectionFactory already exists
+ 10:26:03,107 INFO @main [XmlDeployer] deploying MyExampleConnectionFactory
+ 10:26:03,107 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,118 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,130 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,131 INFO @main [JMSServerManagerImpl] Creating cf ** with ws:1000
+ 10:26:03,133 INFO @main [JBMBootstrapServer] JBM Server Started
+ </programlisting>
+ <para>JBoss Messaging is now running. If any errors are seen, refer to the troubleshooting guide for help</para>
</section>
+
+ <section id="installation.jboss">
+ <title>Installing JBoss Messaging in JBoss AS 5</title>
+ <para>To Do</para>
+ </section>
+
</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/introduction.xml
===================================================================
--- trunk/docs/userguide/en/modules/introduction.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/userguide/en/modules/introduction.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -10,31 +10,20 @@
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
+ <!--<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 performant
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>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>Currently JBM 2.0 is only available standalone or embedded, The current JBoss AS 5 release contains JBM 1.4.2.</para>
- <para>JBoss Messaging is also an integral part of Red Hat's strategy for
- messaging. JBoss Messaging is 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 id="support">
+ <!-- <section id="support">
<title>JBoss Messaging support cover from Red Hat</title>
<para>JBoss Messaging is destined to become part of both Application
@@ -48,11 +37,31 @@
<para>Currently developer support is generally available for JBoss
Messaging when installed in JBoss 4.2.x</para>
- </section>
+ </section>-->
<section id="features">
<title>JBoss Messaging Features</title>
+ <para>New features added since JBM 1.4</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Journal based persistence. todo</para>
+ </listitem>
+
+ <listitem>
+ <para>Mina based transport. todo</para>
+ </listitem>
+
+ <listitem>
+ <para>Native io. todo</para>
+ </listitem>
+
+ <listitem>
+ <para>Standalone and embedded versions. todo</para>
+ </listitem>
+ </itemizedlist>
+
<para>JBoss Messaging provides:</para>
<itemizedlist>
@@ -138,7 +147,7 @@
</listitem>
</itemizedlist>
- <para>Clustering features:</para>
+ <!-- <para>Clustering features:</para>
<itemizedlist>
<listitem>
@@ -200,27 +209,7 @@
geographically separate clusters, forming huge globally
distributed logical queues and topics.</para>
</listitem>
- </itemizedlist>
+ </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>
-
- <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></para>
- </section>
</chapter>
\ No newline at end of file
Added: trunk/docs/userguide/en/modules/journal.xml
===================================================================
--- trunk/docs/userguide/en/modules/journal.xml (rev 0)
+++ trunk/docs/userguide/en/modules/journal.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -0,0 +1,16 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<chapter id="journal">
+ <title>The journal based persistence approach</title>
+ <section id="journal.asyncio">
+ <title>ASYNCIO</title>
+ <para>todo</para>
+ </section>
+ <section id="journal.nio">
+ <title>NIO</title>
+ <para>todo</para>
+ </section>
+ <section id="journal.jdbc">
+ <title>JDBC</title>
+ <para>todo</para>
+ </section>
+</chapter>
\ No newline at end of file
Modified: trunk/docs/userguide/en/modules/runningexamples.xml
===================================================================
--- trunk/docs/userguide/en/modules/runningexamples.xml 2008-05-09 10:46:16 UTC (rev 4166)
+++ trunk/docs/userguide/en/modules/runningexamples.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -1,120 +1,134 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter id="examples">
- <title>Running the Examples</title>
+ <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>In the directory <literal>docs/examples</literal>, you will find 2 sets of examples. A set of pure JMS examples
+ and also a set of non JMS examples that demonstrate how to use the Jboss Messaging core API
+ </para>
+ <para>It is highly recommended that you familiarise yourself with the
+ examples.
+ </para>
+ <para>Make sure you start JBoss Messaging before running the
+ examples!
+ </para>
+ <section id="examples.jms">
+ <title>The JMS examples</title>
+ <para>The following JMS examples are provided. To run these you will first need to start the server as shown
+ in the installation chapter.
+ </para>
- <para>This example shows a simple send and receive to a remote queue
- using a JMS client</para>
- </listitem>
+ <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>to run a specific example open up a shell or command prompt and navigate into the
+ <literal>docs/examples/jms</literal>
+ directory and run the command ant followed by the example name, as follows
+ </para>
+ <programlisting>
+ ant queueExample
+ </programlisting>
+ <para>The output should be similar top the following</para>
+ <programlisting>
+ Buildfile: build.xml
- <listitem>
- <para>docs/example/topic</para>
+ init:
+ [mkdir] Created dir: /home/andy/projects/jBossMessaging/docs/examples/jms/build
- <para>This example shows a simple send and receive to a remote topic
- using a JMS client</para>
- </listitem>
+ compile:
+ [javac] Compiling 5 source files to /home/andy/projects/jBossMessaging/docs/examples/jms/build
- <listitem>
- <para>docs/example/mdb</para>
+ queueExample:
+ [java] 10:59:02,124 INFO @main [QueueExample] sending message to queue
+ [java] 10:59:02,187 INFO @main [QueueExample] message received from queue
+ [java] 10:59:02,187 INFO @main [QueueExample] message = This is a text message!
- <para>This example demonstrates usage of an EJB2.1 MDB with JBoss
- Messaging</para>
- </listitem>
+ BUILD SUCCESSFUL
+ Total time: 3 seconds
+ </programlisting>
+ <para>The following examples are available</para>
+ <itemizedlist>
+ <listitem>
+ <para>queueExample</para>
+ <para>This example shows a simple send and receive to a remote queue
+ using a JMS client
+ </para>
+ </listitem>
+ <listitem>
+ <para>topicExample</para>
+ <para>This example shows a simple send and receive to a remote topic
+ using a JMS client
+ </para>
+ </listitem>
+ <listitem>
+ <para>DurSubExample</para>
+ <para>This example shows the use of a Durable Subscriber.
+ </para>
+ </listitem>
+ <listitem>
+ <para>perfListener</para>
+ <para>This example will run a basic performance test. This needs to be used in conjunction with the
+ perfSender example.
+ </para>
+ </listitem>
+ <listitem>
+ <para>perfSender</para>
+ <para>This example will run a basic performance test. before running start the example and wait for it to
+ start, you will see <literal>READY!!!</literal> when the listener has started. The number of messages,
+ delivery mode can be configured as follows:
+ <programlisting>
+ ant -Dmessage.count=20000 -Ddelivery.mode=PERSISTENT -Dsample.period=1 perfSender
+ </programlisting>
+ <itemizedlist>
+ <listitem>
+ <para>message.count</para>
+ <para>The number of messages to send.</para>
+ </listitem>
+ <listitem>
+ <para>delivery.mode</para>
+ <para>The delivery mode to use, PERSISTENT or NON_PERSISTENT.</para>
+ </listitem>
+ <listitem>
+ <para>message.count</para>
+ <para>The sample period, in seconds</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
- <listitem>
- <para>docs/example/ejb3mdb</para>
+ <section id="examples.messaging">
+ <title>The Messaging examples</title>
+ <para>The messaging examples demonstrate the use of the messaging core API and also how to create and run an embedded
+ instance of JBM. The following examples are available:</para>
+ <para>to run a specific example open up a shell or command prompt and navigate into the
+ <literal>docs/examples/messaging</literal>
+ directory and run the command ant followed by the example name, as follows
+ </para>
+ <programlisting>
+ ant simpleClient
+ </programlisting>
+ <itemizedlist>
+ <listitem>
+ <para>SimpleClient</para>
+ <para>This example shows a simple send and receive to a remote queue
+ using a core messaging client. The server will need to be running for this example.
+ </para>
+ </listitem>
+ <listitem>
+ <para>SSLClient</para>
+ <para>This example shows a simple send and receive to a remote queue using SS. The server will need to be
+ running and configyred to use SSL for this example. Refer to the configuration chapter for details on how to do this
+ </para>
+ </listitem>
+ <listitem>
+ <para>simpleExample</para>
+ <para>This example shows how to create an embedded JBM server using the core API.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
- <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
Added: trunk/docs/userguide/en/modules/troubleshooting.xml
===================================================================
--- trunk/docs/userguide/en/modules/troubleshooting.xml (rev 0)
+++ trunk/docs/userguide/en/modules/troubleshooting.xml 2008-05-09 11:45:40 UTC (rev 4167)
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<chapter id="troubleshooting">
+ <title>Troubleshooting</title>
+</chapter>
\ No newline at end of file
More information about the jboss-cvs-commits
mailing list