[jboss-cvs] JBoss Messaging SVN: r2895 - in trunk/docs/userguide/en: modules and 1 other directory.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri Jul 13 15:40:30 EDT 2007
Author: timfox
Date: 2007-07-13 15:40:29 -0400 (Fri, 13 Jul 2007)
New Revision: 2895
Removed:
trunk/docs/userguide/en/modules/c_overview.xml
Modified:
trunk/docs/userguide/en/master.xml
trunk/docs/userguide/en/modules/about.xml
trunk/docs/userguide/en/modules/bridge.xml
trunk/docs/userguide/en/modules/c_configuration.xml
trunk/docs/userguide/en/modules/configuration.xml
trunk/docs/userguide/en/modules/gettingstarted.xml
trunk/docs/userguide/en/modules/installation.xml
trunk/docs/userguide/en/modules/recovery_config.xml
Log:
Updated userguide
Modified: trunk/docs/userguide/en/master.xml
===================================================================
--- trunk/docs/userguide/en/master.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/master.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -3,7 +3,6 @@
"../../../lib/docbook-support/support/docbook-dtd/docbookx.dtd" [
<!ENTITY about SYSTEM "modules/about.xml">
<!ENTITY introduction SYSTEM "modules/introduction.xml">
-<!ENTITY c_overview SYSTEM "modules/c_overview.xml">
<!ENTITY gettingstarted SYSTEM "modules/gettingstarted.xml">
<!ENTITY nc_installation SYSTEM "modules/installation.xml">
<!ENTITY runningexamples SYSTEM "modules/runningexamples.xml">
@@ -26,8 +25,6 @@
&introduction;
- &c_overview;
-
&gettingstarted;
&nc_installation;
Modified: trunk/docs/userguide/en/modules/about.xml
===================================================================
--- trunk/docs/userguide/en/modules/about.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/modules/about.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -1,6 +1,6 @@
<chapter id="about">
- <title>Introducing JBoss Messaging Release 1.3.0.GA</title>
+ <title>Introducing JBoss Messaging Release 1.4.0.GA</title>
<para>
JBoss Messaging is a high performance JMS provider in the JBoss Enterprise Middleware Stack
@@ -38,7 +38,7 @@
in JBoss Application Server 4.2, there will be no need to do any manual installation.
</para>
- <para>From release 1.3.0.GA onwards JBoss Messaging is designed for JBoss 4.2 only.</para>
+ <para>From release 1.4.0.GA onwards JBoss Messaging is designed for JBoss 4.2 only.</para>
<para>
The procedure of swapping JMS providers is presented in detail in this manual.
@@ -57,11 +57,10 @@
</para>
<para> Permanent Team:
- Tim Fox - Project Lead, Clebert Suconic - Core Developer,
- Sergey Koshcheyev - Core Developer
+ Tim Fox - Project Lead, Clebert Suconic - Core Developer
</para>
- <para>Contributors: Ovidiu Feodorov, Adrian Brock, Alex Fu, Luc Texier, Aaron Walker,
+ <para>Contributors: Sergey Koshcheyev, Adrian Brock, Alex Fu, Luc Texier, Aaron Walker,
Rajdeep Dua, Madhusudhan Konda, Juha Lindfors and Ron Sigal.
</para>
Modified: trunk/docs/userguide/en/modules/bridge.xml
===================================================================
--- trunk/docs/userguide/en/modules/bridge.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/modules/bridge.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -192,6 +192,10 @@
<!-- 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>
@@ -291,6 +295,12 @@
<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>
Modified: trunk/docs/userguide/en/modules/c_configuration.xml
===================================================================
--- trunk/docs/userguide/en/modules/c_configuration.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/modules/c_configuration.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -3,128 +3,29 @@
<title>JBoss Messaging Clustering Configuration</title>
<para>
- In this chapter we will discuss how to configure JBoss Messaging clustering for different types of applications
- </para>
+ JBoss Messaging clustering should work out of the box in most cases with no configuration changes. It is however crucial that every node in the cluster is assigned a unique server id, as specified in the installation guide.
+ </para>
+
+ <para>JBoss Messaging clusters JMS queues and topics transparently across the cluster. Messages sent to a distributed queue or topic on one node are consumable on other nodes. To designate that a particular destination is clustered simply set the clustered attribute in the destination deployment descriptor to true.
+ </para>
+
+ <para>
+JBoss Messaging balances messages between nodes, catering for faster or slower consumers to efficiently balance processing load across the cluster.
+ </para>
+
+ <para>With JBoss Messaging durable subscrtiptions can also be clustered. This means multiple subscribers can consume from the same durable subscription from different nodes of the cluster. A durable subscription will be clustered if it's topic is clustered
+ </para>
+
+ <para>JBoss Messaging also supports clustered temporary topics and queues. All temporary topics and queues will be clustered if the post office is clustered
+ </para>
+
+ <para>If you do want your nodes to participate in a cluster, or only have one non clustered server you can set the clustered attribute on the postoffice to false
+ </para>
+
+ <para>If you wish to apply strict JMS ordering to messages, such that a particular JMS consumer consumes messages in the same order as they were produced by a particular producer, you can set the DefaultPreserveOrdering attribute in the server peer to true. By default this is false. The side-effect of setting this to true is that messages cannot be distributed as freely around the cluster
+ </para>
+
+ <para>When pulling reliable messages from one node to another, by default JBoss Messaging uses an XA transaction to ensure that message was removed from one node and added to another transactionally. Using XA transactions is a fairly heavyweight operation. If you are willing to to relax the reliability guarantee somewhat in order to gain some performance then you can set the attribute UseXAForMessagePull in server peer to false. By default it is true
+ </para>
- <para>
- Most of JBoss messaging clustering configuration revolves around the following variable:
- </para>
-
- <itemizedlist>
-
- <listitem>Choosing the connection factory</listitem>
-
- <listitem>Choosing the cluster router policy</listitem>
-
- <listitem>Choosing the message redistributon policy</listitem>
-
- </itemizedlist>
-
- <section id="clientcluster">
- <title>Choosing the connection factory</title>
-
- <para>JBoss Messaging connections factories can optionally support load balancing and automatic failover. This is determined
- by the attributes on supportsLoadBalancing and supportsFailover on the connection factory.
- </para>
-
- <para>See the section <xref linkend="conf.connectionfactory">Connection Factory configuration</xref> for more information.
- </para>
-
- </section>
-
-
- <section id="clusterrouter">
-
- <title>Choosing the cluster router policy</title>
-
- <para>
-
- When a message is sent to a queue on particular node of the cluster, the system must decide whether the current node will handle it or whether it should send
- it to another node to handle.
- </para>
-
- <para> The same applies if there are shared durable subscriptions on a topic and the message is being sent to a topic
- </para>
-
- <para>The correct decision to make depends on your application topology.</para>
-
- <para>If your application consists of a set of servers with the same MDBs deployed on each server, and you have many well distributed producers sending
- messages on all the nodes of the cluster, then the best policy is to always favour the local queue, since extra network trips are more expensive and the other
- nodes are also havng local messages sent to them</para>
-
- <para>However if your application consists of a set of homogenous MDBs but you have few or badly distributed producers, then always favouring the local producer
- will mean the other nodes are being starved of messages and not using their CPUs cycles efficiently for messaging processing.</para>
-
- <para>In this case, a good policy is to use a round robin routing policy where messages are round robin distributed to different nodes as they arrive.</para>
-
- <para>In general, use the DefaultRoutingPolicy (this always favours the local queue) if you have many well distributed producers, and use the
- RoundRobinRoutingPolicy if you have few or badly distributed producers.</para>
-
- <para>This are specified in the clustered post office config, by specifying the following attribute</para>
-
- <para>To favour the local queue:</para>
-
- <programlisting>
- <attribute name="ClusterRouterFactory">org.jboss.messaging.core.plugin.postoffice.cluster.DefaultRouterFactory</attribute>
- </programlisting>
-
- <para>To round robin:</para>
-
- <programlisting>
- <attribute name="ClusterRouterFactory">org.jboss.messaging.core.plugin.postoffice.cluster.RoundRobinRouterFactory</attribute>
- </programlisting>
-
- </section>
-
-
- <section id="messagepull">
-
- <title>Choosing the message pull policy</title>
-
- <para>Once messages have arrived on queues in a cluster, in an ideal world they will all be consumed at the same rate, and there will be consumers on each node.
- </para>
-
- <para>However, in some application topologies, consumes may close on queues on a node, leaving messages otherwise stranded, or perhaps consumers
- on some nodes are fast than consumers on other nodes causing messages to build up on one node or another and adversely effecting latency.
- </para>
-
- <para>JBoss Messaging allows messages to pulled from one node to another as load dictates in order to cope with such situations</para>
-
- <para>Whether or not you should activate message pulling (message redistribution) depends on your application topology</para>
-
- <para>For an application that consists of a set of servers with a heterogenous bank of MDBs (or other consumers) deployed on each node, consuming at
- approximately the same rate, then message redistribution is not necessary.
- </para>
-
- <para>However, if your application consists of different numbers or rates of consumers on different nodes then message redistribution may help</para>
-
- <warning>By its nature, message redistribution can result in messages being delivered in an order different to the strict ordering imposed by JMS. I.e.
- messages can, sometimes be delivered in an order different to that which they were produced by their producer. If this ordering is important to you
- then don't use message redistribution</warning>
-
- <para>In general, use message redistribution when your consumers are not well distributed across the cluster or if they have greatly varying rates.</para>
-
- <para>Message redistribution is set by setting the following attribute in the clustered post office configuration:
- </para>
-
- <para>
- For no message redistribution:
- </para>
-
- <programlisting>
- <attribute name="MessagePullPolicy">org.jboss.messaging.core.plugin.postoffice.cluster.NullMessagePullPolicy</attribute>
- </programlisting>
-
- <para>For message redistribution:</para>
-
- <programlisting>
- <attribute name="MessagePullPolicy">org.jboss.messaging.core.plugin.postoffice.cluster.DefaultMessagePullPolicy</attribute>
- </programlisting>
-
- <para>When selecting message redistribution you should also choose a value of <literal>StatsSendPeriod</literal> appropriately.</para>
-
- </section>
-
-
-
</chapter>
Deleted: trunk/docs/userguide/en/modules/c_overview.xml
===================================================================
--- trunk/docs/userguide/en/modules/c_overview.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/modules/c_overview.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -1,131 +0,0 @@
-<chapter id="c_overview">
-
-
- <title>JBoss Messaging Clustering</title>
-
- <para>
- This section of the userguide gives a brief overview of the features available in
- JBoss Messaging. It gives a high level explanation of how
- clustering works.
- </para>
-
- <section id="clustering_overview">
- <title>JBoss Messaging Clustering Overview</title>
-
- <para>
- Here's a brief overview of how clustering works in JBoss Messaging
- </para>
-
-
- <para>
- Clustered destinations (queues and topics) can be deployed at all or none of the nodes of
- the cluster.
- A JMS client uses HA JNDI to lookup the connection factory. When creating connections
- using that connection factory a client side load balancing
- policy will automatically chose a node to connect to.
- </para>
-
- <para>
- The JMS client has now made a connection to a node where it can create sessions, message
- producers and message consumers and browsers and send or consume messages,
- using the standard JMS api.
- When a distributed queue is deployed across the cluster, individual partial queues are
- deployed on each node.
- </para>
-
- <para>
- When a message is sent from a message producer attached to a particular node to a
- distributed queue, a routing policy determines which partial queue will receive
- the message.
- By default the router will always pass the message to a local queue, if there is one,
- this is so we avoid unnecessary network traffic.
- If there is no local queue then a partial queue on a different node will be chosen by the
- router, by default this will be round robin between remote partial queues.
- </para>
-
- <para>
- When a message is sent to a distributed topic while attached to a node, there may be
- multiple subscriptions on different nodes that need to receive the
- message. Depending on the number and location of subscriptions, the message may be multicast
- or unicast across the cluster so the other nodes can pick it up.
- (All group communication, unicast, multicast and group management is handled by JGroups.)
- </para>
-
- <para>
- In the case of shared durable subscriptions, if a durable subscription with the same name
- exists on more than node, then only one of the instances needs to receive the message.
- Which one is determined by the same routing policy used to route messages to partial queues.
- All of this is accomplished without losing the reliability guarantees required by JMS.
- </para>
-
- <para>
- Subscriptions (both durable and non durable) can be created on all nodes and will receive messages sent via any node.
- What happens if the consumers on one queue/subscription are faster/slower than consumers on another?
- Normally this would result in messages building up on that queue and fast consumers being starved of work on another, thus wasting CPU cycles on the node that
- could be put to good use.
- The most degenerate example is of a queue containing many messages then the consumers being closed on that queue.
- The messages might potentially remain stranded on the queue until another consumer attaches.
- A routing policy is no use here, since the messages have already been routed to the queuee and the consumers closed / slowed down
- after they were routed there.
- JBoss Messaging can deal with this problem by intelligently pulling messages from other less
- busy nodes, if it detects idle consumers on the fast node and slow consumers
- on another node.
- </para>
-
- </section>
-
-
- <section id="clustering_architectural_overview">
- <title>Clustering Architectural Overview</title>
-
- <para>
- One of the fundamental Messaging Core building blocks is the "Post Office". A JBoss Messaging
- Post Office is message routing component, which accepts messages for delivery and synchronously
- forwards them to their destination queues or topic subscriptions.
- </para>
-
- <para>
- There is a single Post Office instance per JBoss Messaging server (cluster node). Both queues
- and topics deployed on a JBoss Messaging node are "plugged" into that Post Office instance.
- Internally JBoss Messaging only deals with the concepts of queues, and considers a topic to
- just be a set of queues (one for each subscription). Depending on the type of subscription -
- durable or non-durable - the corresponding queue saves messages to persistent storage or
- it just holds messages in memory and discards them when the non-durable subscription is closed.
- </para>
-
- <para>
- Therefore, for a JMS queue, the Post Office routes messages to one and only one core queue,
- depending on the queue name, whereas for a JMS topic, the Post Office routes a message
- to a set of core queues, one for each topic subscription, depending on the topic name.
- </para>
-
- <para>
- Clustering across multiple nodes is achieved by clustering Post Office instances. Each
- JBoss Messaging cluster node runs a Clustered Post Office instance, which is aware of the presence
- of all other clustered Post Offices in the cluster. There is an one-to-one relationship between cluster
- nodes and clustered Post Office instances. So, naturally, the most important piece of clustering
- configuration is the <emphasis>clustered Post Office service configuration</emphasis>,
- covered in detail below.
- </para>
-
- <para>
- Clustered Post Office instances connect to each other via JGroups and they heavily rely on JGroups
- group management and notification mechanisms. <emphasis>JGroups stack configuration</emphasis>
- is an essential part of JBoss Messaging clustering configuration. JGroups configuration is only
- briefly addressed in this guide. 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>
-
- <para>
- When routing messages, a clustered Post Office has a choice of forwarding the message to local
- queues or remote queues, plugged into remote Post Office instances that are part of the same
- cluster. Local queues are usually preferred, but if a local queue is part of a distributed queue, has
- no consumers, and other local queues part of the same distributed queue have consumers, messages
- can be automatically redistributed, subject of the message redistribution policy in effect. This allows
- us to create distributed queues and distributed topics. <emphasis>Message redistribution
- configuration</emphasis> is another subject that we will insist on.
- </para>
-
- </section>
-</chapter>
Modified: trunk/docs/userguide/en/modules/configuration.xml
===================================================================
--- trunk/docs/userguide/en/modules/configuration.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/modules/configuration.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -22,10 +22,7 @@
data is distributed between
<filename>messaging-service.xml</filename>,
<filename>remoting-bisocket-service.xml</filename>,
- <filename>xxx-persistence-service.xml</filename>
- (or <filename>clustered-xxx-persistence-service.xml</filename> for a clustered configuration,
- more about clusterered configuration in <xref linkend="c_configuration"/>) (where xxx is the name
- of the database you are using)
+ <filename>xxx-persistence-service.xml</filename>
<filename>connection-factories-service.xml</filename> and
<filename>destinations-service.xml</filename>.
</para>
@@ -42,7 +39,7 @@
<title>Configuring the ServerPeer</title>
<para>
- The Server Peer is the "heart" of the JBoss Messaging JMS facade. The server's configuration,
+ 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>
@@ -52,35 +49,96 @@
specified in the example</para>
<programlisting>
- <mbean code="org.jboss.jms.server.ServerPeer"
+ <mbean code="org.jboss.jms.server.ServerPeer"
name="jboss.messaging:service=ServerPeer"
xmbean-dd="xmdesc/ServerPeer-xmbean.xml">
- <attribute name="ServerPeerID">0</attribute>
- <attribute name="DefaultQueueJNDIContext">/queue</attribute>
- <attribute name="DefaultTopicJNDIContext">/topic</attribute>
+ <!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer -->
+ <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>
+
<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>
- <attribute name="QueueStatsSamplePeriod">5000</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>
+
+ <!-- Use XA when pulling persistent messages from a remote node to this one. -->
+
+ <attribute name="UseXAForMessagePull">true</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>
<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>
- </mbean>
+ </mbean>
</programlisting>
<section id="conf.serverpeer.attributes">
@@ -90,15 +148,32 @@
<para>
We now discuss the MBean attributes of the ServerPeer MBean
</para>
-
- <section id="conf.serverpeer.attributes.persistencemanager">
- <title>PersistenceManager</title>
+ <section id="conf.serverpeer.attributes.serverpeerid">
+ <title>ServerPeerID</title>
+
<para>
- This is the persistence manager that the ServerPeer uses. You will not normally need to change this attribute.
+ The unique id of the server peer. Each node in the cluster must have a unique name.
</para>
</section>
+ <section id="conf.serverpeer.attributes.defaultqueuejndicontext">
+ <title>DefaultQueueJNDIContext</title>
+
+ <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. Defaults to /topic.
+ </para>
+ </section>
+
+
<section id="conf.serverpeer.attributes.postoffice">
<title>PostOffice</title>
@@ -108,15 +183,49 @@
</para>
</section>
- <section id="conf.serverpeer.attributes.jmsusermanager">
- <title>JMSUserManager</title>
+ <section id="conf.serverpeer.attributes.securitydomain">
+ <title>SecurityDomain</title>
<para>
- This is the JMS user manager that the ServerPeer uses. You will not normally need to change this attribute.
+ The JAAS security domain to be used by this server peer
</para>
</section>
- <section id="conf.serverpeer.attributes.defaultdlq">
+ <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>
@@ -132,9 +241,21 @@
on a per destination basis.
</para>
- </section>
+ </section>
- <section id="conf.serverpeer.attributes.defaultexpiryqueue">
+ <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>
@@ -147,54 +268,35 @@
If the expiry queue is not specified at all then the message will be removed after it is expired.
</para>
- </section>
+ </section>
+ <section id="conf.serverpeer.attributes.defaultredliverydelay">
+ <title>DefaultRedeliveryDelay</title>
- <section id="conf.serverpeer.attributes.serverpeerid">
- <title>ServerPeerID</title>
-
<para>
- The unique id of the server. In a cluster each server MUST have a unique id.
+ 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>
- </section>
-
- <section id="conf.serverpeer.attributes.defaultqueuejndicontext">
- <title>DefaultQueueJNDIContext</title>
-
<para>
- The default JNDI context to use when binding queues. Defaults to /queue.
+ The default value is <literal>0</literal> which means there will be no delay.
</para>
- </section>
-
- <section id="conf.serverpeer.attributes.defaultopicjndicontext">
- <title>DefaultTopicJNDIContext</title>
-
- <para>
- The default JNDI context to use when binding topics. Defaults to /topic.
+ <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>
- <section id="conf.serverpeer.attributes.destinations">
- <title>Destinations</title>
+ <section id="conf.serverpeer.attributes.messagecountersampleperiod">
+ <title>MessageCounterSamplePeriod</title>
<para>
- Returns a list of the destinations (queues and topics) currently deployed.
+ Periodically the server will query each queue to gets its statistics. This is the period.
</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.
+ The default value is <literal>10000</literal> milliseconds
</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>
- <section id="conf.serverpeer.attributes.failoverstarttimeout">
+ <section id="conf.serverpeer.attributes.failoverstarttimeout">
<title>FailoverStartTimeout</title>
<para>
@@ -204,9 +306,9 @@
The default value is <literal>60000</literal> (one minute)
</para>
- </section>
+ </section>
- <section id="conf.serverpeer.attributes.failovercompletetimeout">
+ <section id="conf.serverpeer.attributes.failovercompletetimeout">
<title>FailoverCompleteTimeout</title>
<para>
@@ -215,94 +317,99 @@
<para>
The default value is <literal>300000</literal> (five minutes)
</para>
- </section>
+ </section>
- <section id="conf.serverpeer.attributes.defaultredliverydelay">
- <title>DefaultRedeliveryDelay</title>
+ <section id="conf.serverpeer.attributes.defaultmessagecounterhistorydaylimit">
+ <title>DefaultMessageCounterHistoryDayLimit</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
+ 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 default value is <literal>0</literal> which means there will be no delay.
+ The name of the connection factory to use for pulling messages between nodes. You will not normally need to change this
</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>
- <section id="conf.serverpeer.attributes.queuestatssampleperiod">
- <title>QueueStatsSamplePeriod</title>
+ <section id="conf.serverpeer.attributes.usexaformessagepull">
+ <title>UseXAForMessagePull</title>
<para>
- Periodically the server will query each queue to gets its message statistics. This is the period.
+ If true, then move a reliable message from one node to another in an XA transaction. Relaxing this gives better performance at the expense of some reliability. See the cluster configurations section for more details. Default is true
</para>
+ </section>
+
+ <section id="conf.serverpeer.attributes.defaultpreserveordering">
+ <title>DefaultPreserveOrdering</title>
+
<para>
- The default value is <literal>10000</literal> milliseconds
+ 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>
- <section id="conf.serverpeer.attributes.defaultmessagecounterhistorydaylimit">
- <title>DefaultMessageCounterHistoryDayLimit</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.destinations">
+ <title>Destinations</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
+ Returns a list of the destinations (queues and topics) currently deployed.
</para>
- </section>
+ </section>
- <section id="conf.serverpeer.attributes.messagecounters">
+ <section id="conf.serverpeer.attributes.messagecounters">
<title>MessageCounters</title>
<para>
JBoss Messaging provides a message counter for each queue.
</para>
- </section>
+ </section>
- <section id="conf.serverpeer.attributes.messagecounterstatistics">
+ <section id="conf.serverpeer.attributes.messagecounterstatistics">
<title>MessageCountersStatistics</title>
<para>
JBoss Messaging provides statistics for each message counter for each queue.
</para>
- </section>
+ </section>
- <section id="conf.serverpeer.attributes.defaultsecurity">
- <title>DefaultSecurityConfig</title>
+ <section id="conf.serverpeer.attributes.supportsfailover">
+ <title>SupportsFailover</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.
+ Set to false to prevent server side failover occurring in a cluster when a node crashes.
</para>
+ </section>
- <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>
+ <section id="conf.serverpeer.attributes.persistencemanager">
+ <title>PersistenceManager</title>
<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.
+ 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>
- If the <literal>create</literal> attribute is <literal>true</literal> then that role
- will be able to create durable subscriptions on topics by default.
+ This is the JMS user manager that the ServerPeer uses. You will not normally need to change this attribute.
</para>
- </section>
</section>
@@ -473,6 +580,8 @@
</section>
</section>
+
+ </section>
<section id="conf.changingds">
<title>Changing the Database</title>
@@ -524,125 +633,72 @@
<para>The post office also handles the persistence for the mapping of addresses</para>
- <para>JBoss Messaging comes with two different post office implementations - depending on whether you want clustering or not. The clustered post office
- has the ability to route messages to other nodes in the cluster</para>
+ <para>JBoss messaging are also cluster aware. In a cluster they will automatically route and pull messages between them in order to provide fully distributed JMS queues and topics.</para>
- <para>Whether you use the clustered post office or not depends on whether you deploy the <literal>clustered-xxx-persistence-service.xml</literal> MBean config
- or just the non clustered <literal>xxx-persistence-service.xml</literal> file.</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>It is likely that in future releases of JBoss Messaging the clustered and non clustered post offices will be combined into a single post office for
- ease of configuration</para>
+ <para>Here is an example of a post office configuration:</para>
- <section id="conf.postoffice.nonclustered">
- <title>Non clustered post office</title>
-
- <para>The non clustered post office should be used where clustering is not required. It will be used when the
- non clustered <literal>xxx-persistence-service.xml</literal> file is deployed.</para>
-
- <para>Here is an example of a non clustered post office configuration:</para>
-
- <programlisting>
- <mbean code="org.jboss.messaging.core.plugin.DefaultPostOfficeService"
+ <programlisting>
+<mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService"
name="jboss.messaging:service=PostOffice"
- xmbean-dd="xmdesc/DefaultPostOffice-xmbean.xml">
+ 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>
- <attribute name="PostOfficeName">JMS</attribute>
+
+ <!-- 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(1023), COND VARCHAR(1023), SELECTOR VARCHAR(1023), CHANNEL_ID BIGINT, CLUSTERED CHAR(1))
-INSERT_BINDING=INSERT INTO JBM_POSTOFFICE (POSTOFFICE_NAME, NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED) VALUES (?, ?, ?, ?, ?, ?, ?)
+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 NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME = ?
+LOAD_BINDINGS=SELECT QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED, ALL_NODES FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=?
]]></attribute>
- </mbean>
-
- </programlisting>
-
- <section id="conf.postoffice.nonclustered.attributes">
-
- <title>The non clustered post office has the following attributes</title>
-
- <section id="conf.postoffice.nonclustered.attributes.datasource">
- <title>DataSource</title>
- <para>The datasource the postoffice should use for persisting its mapping data</para>
- </section>
-
- <section id="conf.postoffice.nonclustered.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.nonclustered.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.nonclustered.attributes.postofficename">
- <title>PostOfficeName</title>
-
- <para>
- The name of the post office
- </para>
- </section>
- </section>
- </section>
-
-
- <section id="conf.postoffice.clustered">
- <title>Clustered post office</title>
-
- <para>The clustered post office should be used where clustering is required. It will be used when the
- clustered <literal>clustered-xxx-persistence-service.xml</literal> file is deployed.</para>
-
- <para>Here is an example of a clustered post office configuration:</para>
-
- <programlisting>
- <mbean code="org.jboss.messaging.core.plugin.ClusteredPostOfficeService"
- name="jboss.messaging:service=PostOffice"
- xmbean-dd="xmdesc/ClusteredPostOffice-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>
- <attribute name="PostOfficeName">Clustered JMS</attribute>
- <attribute name="DataSource">java:/DefaultDS</attribute>
- <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(1023), COND VARCHAR(1023), SELECTOR VARCHAR(1023), CHANNEL_ID BIGINT, CLUSTERED CHAR(1))
-INSERT_BINDING=INSERT INTO JBM_POSTOFFICE (POSTOFFICE_NAME, NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED) VALUES (?, ?, ?, ?, ?, ?, ?)
-DELETE_BINDING=DELETE FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME=? AND NODE_ID=? AND QUEUE_NAME=?
-LOAD_BINDINGS=SELECT NODE_ID, QUEUE_NAME, COND, SELECTOR, CHANNEL_ID, CLUSTERED FROM JBM_POSTOFFICE WHERE POSTOFFICE_NAME = ?
- ]]></attribute>
- <attribute name="GroupName">DefaultPostOffice</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">MessagingPostOffice</attribute>
+
+ <!-- Max time to wait for state to arrive when the post office joins the cluster -->
+
<attribute name="StateTimeout">5000</attribute>
- <attribute name="CastTimeout">5000</attribute>
- <attribute name="StatsSendPeriod">3000</attribute>
- <attribute name="MessagePullPolicy">org.jboss.messaging.core.plugin.postoffice.cluster.NullMessagePullPolicy</attribute>
- <attribute name="ClusterRouterFactory">org.jboss.messaging.core.plugin.postoffice.cluster.DefaultRouterFactory</attribute>
-
-
- <attribute name="ChannelFactoryName">jgroups.mux:name=Multiplexer</attribute>
- <attribute name="SyncChannelName">udp-sync</attribute>
- <attribute name="AsyncChannelName">udp</attribute>
+
+ <!-- Max time to wait for a synchronous call to node members using the MessageDispatcher -->
+
+ <attribute name="CastTimeout">50000</attribute>
+
+ <!-- Enable this when the JGroups multiplexer comes of age
+ <attribute name="ChannelFactoryName">jgroups.mux:name=Multiplexer</attribute>
+ <attribute name="ControlChannelName">udp-sync</attribute>
+ <attribute name="DataChannelName">udp</attribute>
<attribute name="ChannelPartitionName">${jboss.partition.name:DefaultPartition}-JMS</attribute>
-
- <attribute name="AsyncChannelConfig">
+ -->
+
+ <!-- JGroups stack configuration for the data channel - used when casting messages across the cluster -->
+
+ <attribute name="DataChannelConfig">
<config>
<UDP mcast_recv_buf_size="500000" down_thread="false" ip_mcast="true" mcast_send_buf_size="32000"
mcast_port="45567" ucast_recv_buf_size="500000" use_incoming_packet_handler="false"
@@ -662,8 +718,10 @@
<pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false" join_retry_timeout="2000" up_thread="false" shun="true"/>
</config>
</attribute>
-
- <attribute name="SyncChannelConfig">
+
+ <!-- JGroups stack configuration to use for the control channel - used for bind/unbind requests amongst others -->
+
+ <attribute name="ControlChannelConfig">
<config>
<UDP mcast_recv_buf_size="500000" down_thread="false" ip_mcast="true" mcast_send_buf_size="32000"
mcast_port="45568" ucast_recv_buf_size="500000" use_incoming_packet_handler="false"
@@ -685,173 +743,124 @@
</config>
</attribute>
</mbean>
+ </programlisting>
+
+ <section id="conf.postoffice.attributes">
- </programlisting>
+ <title>The post office has the following attributes</title>
- <section id="conf.postoffice.clustered.attributes">
+ <section id="conf.postoffice.attributes.datasource">
+ <title>DataSource</title>
+ <para>The datasource the postoffice should use for persisting its mapping data</para>
+ </section>
- <title>The clustered post office has the following attributes</title>
+ <section id="conf.postoffice.attributes.sqlproperties">
+ <title>SQLProperties</title>
+ <para>
+ This is where the DDL and DML for the particular database is specified.
+ If a particular DDL or DML statement is not overridden, the default Hypersonic
+ configuration will be used for that statement.
+ </para>
+ </section>
- <section id="conf.postoffice.clustered.attributes.datasource">
- <title>DataSource</title>
- <para>The datasource the postoffice should use for persisting its mapping data</para>
- </section>
+ <section id="conf.postoffice.attributes.createtables">
+ <title>CreateTablesOnStartup</title>
- <section id="conf.postoffice.clustered.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.clustered.attributes.createtables">
- <title>CreateTablesOnStartup</title>
-
- <para>
+ <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>
+ </para>
+ <para>
By default the value of <literal>CreateTablesOnStartup</literal> attribute
is set to <literal>true</literal>
- </para>
- </section>
+ </para>
+ </section>
- <section id="conf.postoffice.clustered.attributes.postofficename">
- <title>PostOfficeName</title>
+ <section id="conf.postoffice.attributes.postofficename">
+ <title>PostOfficeName</title>
- <para>
+ <para>
The name of the post office
- </para>
- </section>
+ </para>
+ </section>
- <section id="conf.postoffice.clustered.attributes.nodeidview">
- <title>NodeIDView</title>
+ <section id="conf.postoffice.attributes.nodeidview">
+ <title>NodeIDView</title>
- <para>
+ <para>
This returns set containing the node ids of all the nodes in the cluster
- </para>
- </section>
+ </para>
+ </section>
- <section id="conf.postoffice.clustered.attributes.groupname">
- <title>GroupName</title>
+ <section id="conf.postoffice.attributes.groupname">
+ <title>GroupName</title>
- <para>
+ <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>
+ </para>
+ </section>
- <section id="conf.postoffice.clustered.attributes.messagepullpolicy">
- <title>MessagePullPolicy</title>
- <para>
- JBoss Messaging has the ability for queues on one node to pull messages from other nodes when they have exhausted their local messages.
- </para>
- <para>This prevents messages from getting stranded on nodes with slow or no consumers, and balances out message processing across the cluster.</para>
- <para>How, if and when messages are pulled from one node to another is determined by the MessagePullPolicy</para>
- <para>By default this set to <literal>org.jboss.messaging.core.plugin.postoffice.cluster.NullMessagePullPolicy</literal> which is a dummy
- implementation which never pulls messages from one node to another.</para>
- <para>Whether you need message redistribution or not depends on your application topology - please see the section on clustering configuration for
- more details</para>
- <para>If you require message redistribution then set this value to <literal>org.jboss.messaging.core.plugin.postoffice.cluster.NullMessagePullPolicy</literal>
- </para>
- <warning>Enabling message redistribution can result in the strict JMS message ordering guarantee being lost (i.e. the order of receipt of messages from
- a particular producer is retained). If this is not acceptable then do not enable message redistribution.</warning>
- </section>
+ <section id="conf.postoffice.attributes.clustered">
+ <title>Clustered</title>
- <section id="conf.postoffice.clustered.attributes.clusterrouterfactory">
- <title>ClusterRouterFactory</title>
- <para>
- When a message arrives on a node - JBoss Messaging needs to decide whether to route it to a local queue or a remote queue on a different node.
- </para>
- <para>This setting allows you to specify the factory that determines this routing</para>
- <para>By default this set to <literal>org.jboss.messaging.core.plugin.postoffice.cluster.DefaultRouterFactory</literal> which always favours
- a local queue if one is available otherwise it round robins amongst other queues.</para>
- <para>The particular router factory you require depends on your application topology - please see the section on clustering configuration for
- more details</para>
- <para>Other values this attribute can be set to are <literal>org.jboss.messaging.core.plugin.postoffice.cluster.RoundRobinRouterFactory</literal>
- if you do not want to favour the local queue.
- </para>
- </section>
+ <para>
+ If true the post office will take part in a cluster to form distributed queues and topics. If false then it will not participate in the cluster. If false, then all the cluster related attributes will be ignored.
+ </para>
+ </section>
- <section id="conf.postoffice.clustered.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.
+ <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>
- <para>The default value is <literal>5000</literal> milliseconds
- </para>
- </section>
+ </section>
- <section id="conf.postoffice.clustered.attributes.casttimeout">
- <title>CastTimeout</title>
- <para>
+ <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>
+ </para>
+ <para>The default value is <literal>5000</literal> milliseconds
+ </para>
+ </section>
- <section id="conf.postoffice.clustered.attributes.statssendperiod">
- <title>StatsSendPeriod</title>
- <para>
- When clustering, each node in the cluster will broadcast statistics periodically to inform the other nodes of their queues and the number of
- messages in them. This data is then used by the message redistribution policy to redistribute messages if necessary.
- This value represents the number of milliseconds between statistics broadcasts.
- </para>
- <para>
- The default value is <literal>10000</literal> milliseconds
- </para>
- </section>
-
- <section id="conf.postoffice.clustered.attributes.syncchannelconfig">
- <title>SyncChannelConfig</title>
- <para>
- JBoss Messaging uses JGroups for all group management. This contains the JGroups stack configuration for the synchronous channel.
- </para>
- <para>The synchronous channel is used for sending request/reeciving responses from other nodes in the cluster</para>
- <para>
+ <section id="conf.postoffice.attributes.controlchannelconfig">
+ <title>ControlChannelConfig</title>
+ <para>JBoss Messaging uses JGroups for all group management. This contains the JGroups stack configuration for the control channel.
+ </para>
+ <para>The control channel is used for sending request/receiving responses from other nodes in the cluster</para>
+ <para>
The details of the JGroups configuration won't be discussed here since it is standard JGroups configuration.
Detailed information on JGroups can be found in JGroups release documentation or on-line at
<ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink> or
<ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups</ulink>
- </para>
- </section>
+ </para>
+ </section>
- <section id="conf.postoffice.clustered.attributes.asyncchannelconfig">
- <title>AsyncChannelConfig</title>
+ <section id="conf.postoffice.attributes.asyncchannelconfig">
+ <title>DataChannelConfig</title>
<para>
- JBoss Messaging uses JGroups for all group management. This contains the JGroups stack configuration for the asynchronous channel.
+ JBoss Messaging uses JGroups for all group management. This contains the JGroups stack configuration for the data channel.
</para>
- <para>The asynchronous channel is used for sending sending/receiving messages from other nodes in the cluster</para>
+ <para>The data channel is used for sending sending/receiving messages from other nodes in the cluster</para>
<para>
The details of the JGroups configuration won't be discussed here since it is standard JGroups configuration.
Detailed information on JGroups can be found in JGroups release documentation or on-line at
<ulink url="http://www.jgroups.org">http://www.jgroups.org</ulink> or
<ulink url="http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups">http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups</ulink>
</para>
- </section>
-
- <section id="conf.postoffice.clustered.attributes.threadpoolsize">
- <title>ThreadPoolSize</title>
- <para>
- The post office uses a thread pool for dispatching requests/handling responses from the cluster. This attribute represents the maximum size of
- that pool
- </para>
- <para>The default value of this is <literal>50</literal> threads</para>
- </section>
-
- </section>
- </section>
+ </section>
+
</section>
-
-
-
- <section id="conf.persistencemanager">
+
+ </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.
@@ -912,82 +921,76 @@
<programlisting>
- <mbean code="org.jboss.messaging.core.plugin.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>
- <attribute name="DataSource">java:/DefaultDS</attribute>
- <attribute name="CreateTablesOnStartup">true</attribute>
- <attribute name="UsingBatchUpdates">false</attribute>
- <attribute name="MaxParams">500</attribute>
- </mbean>
-
+ <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_MESSAGE=CREATE TABLE JBM_MSG (MESSAGE_ID BIGINT, RELIABLE CHAR(1), EXPIRATION BIGINT, TIMESTAMP BIGINT, PRIORITY TINYINT, HEADERS MEDIUMBLOB, PAYLOAD LONGBLOB, CHANNEL_COUNT INTEGER, TYPE TINYINT, PRIMARY KEY (MESSAGE_ID)) ENGINE = INNODB
+ CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (CHANNEL_ID BIGINT, MESSAGE_ID BIGINT REFERENCES JBM_MSG(MESSAGE_ID), 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_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_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, HEADERS, PAYLOAD, CHANNEL_COUNT, TYPE) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
+ INC_CHANNEL_COUNT=UPDATE JBM_MSG SET CHANNEL_COUNT = CHANNEL_COUNT + 1 WHERE MESSAGE_ID=?
+ DEC_CHANNEL_COUNT=UPDATE JBM_MSG SET CHANNEL_COUNT = CHANNEL_COUNT - 1 WHERE MESSAGE_ID=?
+ DELETE_MESSAGE=DELETE FROM JBM_MSG WHERE MESSAGE_ID=? AND CHANNEL_COUNT=0
+ MESSAGE_ID_COLUMN=MESSAGE_ID
+ MESSAGE_EXISTS=SELECT MESSAGE_ID FROM JBM_MSG WHERE MESSAGE_ID = ? FOR UPDATE
+ 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>
-
- <para>
- An example of a Persistence Manager configuration for a MySQL database follows:
- </para>
-
- <programlisting>
-
- <mbean code="org.jboss.messaging.core.plugin.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>
- <attribute name="DataSource">java:/DefaultDS</attribute>
- <attribute name="CreateTablesOnStartup">true</attribute>
- <attribute name="UsingBatchUpdates">true</attribute>
- <attribute name="SqlProperties"><![CDATA[
- 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))
- 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, HEADERS MEDIUMBLOB, PAYLOAD LONGBLOB, CHANNEL_COUNT INTEGER, TYPE TINYINT, PRIMARY KEY (MESSAGE_ID))
- CREATE_TRANSACTION=CREATE TABLE JBM_TX (TRANSACTION_ID BIGINT, BRANCH_QUAL VARBINARY(254), FORMAT_ID INTEGER, GLOBAL_TXID VARBINARY(254), PRIMARY KEY (TRANSACTION_ID))
- CREATE_COUNTER=CREATE TABLE JBM_COUNTER (NAME VARCHAR(255), NEXT_ID BIGINT, PRIMARY KEY(NAME))
- 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=SELECT MESSAGE_ID FROM JBM_MSG_REF WHERE CHANNEL_ID = ? AND MESSAGE_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, HEADERS, PAYLOAD, CHANNEL_COUNT, TYPE) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
- INC_CHANNEL_COUNT=UPDATE JBM_MSG SET CHANNEL_COUNT = CHANNEL_COUNT + 1 WHERE MESSAGE_ID=?
- DEC_CHANNEL_COUNT=UPDATE JBM_MSG SET CHANNEL_COUNT = CHANNEL_COUNT - 1 WHERE MESSAGE_ID=?
- DELETE_MESSAGE=DELETE FROM JBM_MSG WHERE MESSAGE_ID=? AND CHANNEL_COUNT=0
- MESSAGE_ID_COLUMN=MESSAGE_ID
- MESSAGE_EXISTS=SELECT MESSAGE_ID FROM JBM_MSG WHERE MESSAGE_ID = ? FOR UPDATE
- INSERT_TRANSACTION=INSERT INTO JBM_TX (TRANSACTION_ID, BRANCH_QUAL, FORMAT_ID, GLOBAL_TXID) VALUES(?, ?, ?, ?)
- DELETE_TRANSACTION=DELETE FROM JBM_TX WHERE TRANSACTION_ID = ?
- SELECT_PREPARED_TRANSACTIONS=SELECT TRANSACTION_ID, BRANCH_QUAL, FORMAT_ID, GLOBAL_TXID FROM JBM_TX
- 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
- ]]></attribute>
- <attribute name="MaxParams">500</attribute>
- </mbean>
-
-
- </programlisting>
<section id="conf.persistencemanager.attributes">
@@ -1078,9 +1081,9 @@
</section> <!-- end conf.persistencemanager.attributes -->
- </section> <!-- end conf.persistencemanager -->
+ </section> <!-- end conf.persistencemanager -->
- <section id="conf.jmsusermanager">
+ <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
@@ -1089,7 +1092,6 @@
<para>Here is an example JMSUserManager configuration</para>
<programlisting>
-
<mbean code="org.jboss.jms.server.plugin.JDBCJMSUserManagerService"
name="jboss.messaging:service=JMSUserManager"
xmbean-dd="xmdesc/JMSUserManager-xmbean.xml">
@@ -1098,13 +1100,12 @@
<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))
-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))
+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">
@@ -1162,10 +1163,10 @@
</section> <!-- end conf.jmsusermanager.attributes -->
- </section> <!-- end.conf.jmsusermanager -->
+ </section> <!-- end.conf.jmsusermanager -->
- <section id="conf.destination">
+ <section id="conf.destination">
<title>Configuring Destinations</title>
<section id="conf.preconf.destinations">
@@ -1501,7 +1502,7 @@
<title>Clustered</title>
<para>
- Clustered destinations must have this set to <literal>true</literal>
+ Clustered destinations must have this set to <literal>true</literal>.
</para>
</section>
@@ -1963,8 +1964,10 @@
</section>
</section>
+
+ </section> <!-- end of conf destination -->
- <section id="conf.connectionfactory">
+ <section id="conf.connectionfactory">
<title>Configuring Connection Factories</title>
<para>
@@ -2181,10 +2184,10 @@
that creates connections that use the bisocket transport to communicate.</para>
</section>
</section> <!-- End conf.connectionfactory.attributes -->
- </section> <!-- End conf.connectionfactory -->
+ </section> <!-- End conf.connectionfactory -->
- <section id="conf.connector">
+ <section id="conf.connector">
<title>Configuring the remoting connector</title>
<para>
@@ -2276,6 +2279,5 @@
</section> <!-- End conf.callback -->
- </section> <!-- End conf -->
-
+
</chapter>
Modified: trunk/docs/userguide/en/modules/gettingstarted.xml
===================================================================
--- trunk/docs/userguide/en/modules/gettingstarted.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/modules/gettingstarted.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -15,8 +15,8 @@
<title>The JBoss Messaging Release Bundle</title>
<para>
- The JBoss Messaging release bundle (<filename>jboss-messaging-1.3.x.zip</filename>)
- will expand in a <filename>jboss-messaging-1.3.x</filename> directory that contains:
+ The JBoss Messaging release bundle (<filename>jboss-messaging-1.4.x.zip</filename>)
+ will expand in a <filename>jboss-messaging-1.4.x</filename> directory that contains:
</para>
<itemizedlist>
Modified: trunk/docs/userguide/en/modules/installation.xml
===================================================================
--- trunk/docs/userguide/en/modules/installation.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/modules/installation.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -12,6 +12,8 @@
Messaging, you need to perform the installation procedure described
below.</para>
+ <para>JBoss Messaging requires Java 5 or later</para>
+
<para>
<note>
A JBossMQ and a JBoss Messaging instance cannot coexist, at least not unless special precautions are taken.
@@ -43,22 +45,13 @@
<itemizedlist>
- <listitem>If you do not want clustering functionality and have a completely clean JBoss AS 4.2.0 installation
- then you can do an <xref linkend="install.automated">automatic non-clustered install</xref>.
+ <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 do not want clustering functionality and have a JBoss 4.2.0 that you have changed in some
+ <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 non-clustered install</xref>.
- </listitem>
-
- <listitem>If you want clustering functionality and have a completely clean JBoss AS 4.2.0 installation
- then you can do an <xref linkend="install.automatedclustered">automatic clustered install</xref>.
- </listitem>
-
- <listitem>If you want clustering functionality and 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.manualclustered">manual clustered install</xref>.
+ <xref linkend="install.manual">manual install</xref>.
</listitem>
<listitem><warning>Not recommended!</warning>If you to install in JBoss 4.0.x and are willing to cope
@@ -68,228 +61,10 @@
</itemizedlist>
-
-
<section id="install.automated">
- <title>Automated Non-clustered Installation from clean JBoss AS 4.2 installation</title>
+ <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 JBoss Messaging installation
- </note>
- </para>
-
- <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. Run the installation script, available in the
- <filename>util</filename> directory of the release bundle.</para>
-
- <programlisting>
- cd util
- ant -f release-admin.xml
- </programlisting>
-
- <para>The installation script will create a
- <filename>$JBOSS_HOME/server/messaging</filename> configuration.</para>
-
- <para>
- <para><warning>For use in production it is highly recommended to use a
- different database other than the HSQLDB. HSQLDB does not have any transaction isolation.
- For simple non clustered development evaluation HSQLDB may suffice.
- If you decide to use a different database please follow the follow steps:
- </warning></para>
-
- <itemizedlist>
- <listitem>
- <para>Replace
- <literal>JBOSS_CONFIG/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml</literal>
- by the persistence-service of from
- <literal><downloadPackage>/examples/config.</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 providers
- web site</para>
- </listitem>
-
- </itemizedlist>
- </para>
-
- <para>There are few extra steps at <xref
- linkend="install.extra-steps" /></para>
-
- <para>That's it!</para>
-
- <note>
- <para>If you want to create a JBoss Messaging configuration with a
- different name, you can specify the <literal>messaging.config.name</literal>
- system property when you run the command:</para>
-
- <programlisting>
- cd util
- ant -f release-admin.xml -Dmessaging.config.name=mymessaging
- </programlisting>
- </note>
- </section>
-
- <section id="install.manual">
- <title>Manual Non-clustered 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/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>
-
- </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 sar 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 use in production it is highly recommended to use a
- different database other than the HSQLDB. HSQLDB does not have any transaction isolation.
- For simple non clustered development evaluation HSQLDB may suffice.
- If you decide to use a different database please follow the follow steps:
- </warning></para>
-
- <itemizedlist>
- <listitem>
- <para>Replace
- <literal>JBOSS_CONFIG/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml</literal>
- by the persistence-service of from
- <literal><downloadPackage>/examples/config.</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 providers
- web site</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.automatedclustered">
- <title>Clustered 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
@@ -339,9 +114,9 @@
<listitem>
<para>Replace
<literal>$JBOSS_CONFIG/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml</literal>
- by the <literal>clustered-<databasename>-persistence-service</literal> from
+ by the <literal>databasename>-persistence-service</literal> from
<literal><downloadPackage>/examples/config.</literal>. For instance
- <literal>clustered-mysql-persistence-service.xml</literal>
+ <literal>mysql-persistence-service.xml</literal>
</para>
</listitem>
@@ -450,8 +225,8 @@
- <section id="install.manualclustered">
- <title>Clustered Manual Installation</title>
+ <section id="install.manual">
+ <title>Manual Installation</title>
<para>
<note>This installation procedure should be performed if you are installing into a JBoss AS
@@ -556,9 +331,9 @@
<listitem>
<para>Replace
<literal>$JBOSS_CONFIG/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml</literal>
- by the <literal>clustered-<databasename>-persistence-service</literal> from
+ by the <literal>databasename>-persistence-service</literal> from
<literal><downloadPackage>/examples/config.</literal>. For instance
- <literal>clustered-mysql-persistence-service.xml</literal>
+ <literal>mysql-persistence-service.xml</literal>
</para>
</listitem>
@@ -749,79 +524,7 @@
</section>
</section>
- <section id="install.jboss40x">
- <title>JBoss Messaging on JBoss 4.0.x</title>
- <warning>
- You should avoid using JBossMessaging on any version prior to JBoss 4.2.0.GA,
- such as 4.0.5.GA and 4.0.4.GA.
- JBoss Messaging uses newer versions of JBoss AOP, JBoss Remoting and JGroups compared to JBoss 4.0.X.
- If you really need to install JBoss Messaging on those versions you will have to update those jars
- as described on this section but this might cause problems with other components such as JBoss Web
- Services and EJB3, and may cause other parts of JBoss AS to stop functioning.
- Also there may be support implications when running in this configuration since the installation
- procedure requires overwriting some of the jars in JBoss AS. Do this at your own peril!
- </warning>
-
- <itemizedlist>
- <listitem>
- <para>Install JBoss Messaging using the most convenient way described
- on the <link linkend="installation">previous section</link> using the
- default configuration as your base (even for a clustered JBoss
- Messaging)</para>
- </listitem>
-
- <listitem>
- <para>Replace the jars on this following list. You can download
- these jars the repository links provided
- below:</para>
-
- <itemizedlist>
- <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>
- </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/jboss-remoting.jar</para>
-
- <para>JBoss Remoting 2.2.0.SP4+</para>
-
- <para><ulink
- url="http://repository.jboss.com/jboss/remoting/2.2.0.SP4/lib/">http://repository.jboss.com/jboss/remoting/2.2.0.SP4/lib/</ulink></para>
- </listitem>
-
- <listitem>
- <para>$JBOSS_HOME/server/<SERVER_NAME>/lib/jgroups.jar (if
- using a clustered configuration)</para>
-
- <para>JGroups 2.4.1.SP3-brew+</para>
-
- <para><ulink
- url="http://repository.jboss.com/jgroups/2.4.1.SP3-brew/lib/">http://repository.jboss.com/jgroups/2.4.1.SP3-brew/lib/</ulink></para>
- </listitem>
- </itemizedlist>
- </listitem>
-
- </itemizedlist>
- </section>
-
<section id="startingtheservice">
<title>Starting the Server</title>
@@ -850,7 +553,7 @@
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.3.0.GA server [0] started
+13:19:15,166 INFO [ServerPeer] JBoss Messaging 1.4.0.CR1 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:/ConnectionFactory, java:/XAConnectionFactory] started
13:19:15,412 WARN [ConnectionFactoryJNDIMapper] supportsFailover attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support failover
@@ -965,7 +668,7 @@
[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.3.0.GA (1.3)
+ [java] The example connected to JBoss Messaging version 1.4.0.CR1 (1.4)
[java] #####################
[java] ### SUCCESS! ###
Modified: trunk/docs/userguide/en/modules/recovery_config.xml
===================================================================
--- trunk/docs/userguide/en/modules/recovery_config.xml 2007-07-13 17:44:15 UTC (rev 2894)
+++ trunk/docs/userguide/en/modules/recovery_config.xml 2007-07-13 19:40:29 UTC (rev 2895)
@@ -46,6 +46,9 @@
"com.arjuna.ats.jta.recovery.XAResourceRecovery.JBMESSAGING2, ..." etc.</para>
<para>In actual fact, the recovery also should work with any JMS provider that implements recoverable XAResources (i.e. it properly implements XAResource.recover())
, not just JBoss Messaging</para>
+
+ <para>Please note that to configure the recovery manager to recovery transactions from any node of the cluster it will be necessary to specify a line in the configuration for every node of the cluster
+ </para>
More information about the jboss-cvs-commits
mailing list