Copyright © 2008 Red Hat, Inc
Copyright © 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License (which is presently available at http://creativecommons.org/licenses/by-nc-sa/3.0/).
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the security@redhat.com key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E
1801 Varsity Drive
Raleigh, NC 27606-2072
USA
Phone: +1 919 754 3700
Phone: 888 733 4281
Fax: +1 919 754 3701
PO Box 13588
Research Triangle Park, NC 27709
USA
Oct, 2007
This User Guide documents relevant information regarding the usage of JBoss Messaging 1.4 for JBoss Enteprise Application Platform 4.3
The goal of this book is to give you an overview of JBoss Messaging. It explains the important features of JBoss Messaging and its capability to provide a high-performance and robust messaging system for Enterprise Java Applications.
JBoss Messaging is the new state-of-the-art enterprise messaging system from JBoss, providing superior performance, reliability and scalability with high throughput and low latency. JBoss Messaging has replaced JBossMQ as the default JMS provider in JBoss Enterprise Application Platform 4.3. The version used is JBoss Messaging 1.4. You should use this version or later with the examples demonstrating JBoss Messaging. The book is not intended to teach you the basics of Enterprise Messaging. Use it to familiarize with JBoss Messaging features and various configurations.
JBoss Messaging provides an open source and standards-based messaging platform and is an integral part of Red Hat's strategy for enterprise messaging. It is a complete rewrite of JBossMQ, the legacy JBoss JMS provider, and offers improved performance in both single node and clustered environments. It also features a much better modular architecture that allows easy adding of new features in the future.
JBoss Messaging 1.4 is the default JMS provider in JBoss Enterprise Application Platform 4.3.
If you spot a typo in this guide, or if you have thought of a way to make this manual better, we would love to hear from you! Submit a report in JIRA against the Product: JBoss Enterprise Application Platform, Version: <version>, Component: Doc. If you have a suggestion for improving the documentation, try to be as specific as possible. If you have found an error, include the section number and some of the surrounding text so we can find it easily.
If you are looking for detailed product information refer to the manuals available online at http://www.redhat.com/docs/manuals/jboss.
JBossMQ has two fundamental limitations:
JBossMQ is based on SpyderMQ (the open source project) which is a non-clustered broker.
The threading model and the overall design of the non-clustered broker leads to performance limitations in certain high load usage scenarios.
JBoss Messaging implements a high-performance and robust messaging core that is designed to support the largest and most heavily utilized Service Oriented Architectures(SOAs), Enterprise Service Buses (ESBs) and other integration needs ranging from the simplest to the highest demand networks.
It will allow you to smoothly distribute your application load across your cluster, intelligently balancing and utilizing each node's CPU cycles. It comes with no single point of failure and no single point of bottleneck, sophisticated and fully configurable message expiration handling and XA transaction recovery. Thus providing a highly scalable and performant clustering implementation. It 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.
JMS compliance: A fully compatible and Sun certified JMS 1.1 implementation, that currently works with JBoss Enterprise Application Platform 4.3 or JBoss Application Server version 4.2 or later.
JBoss Messaging contains a host of other features, including:
Publish-subscribe and point-to-point messaging models
Persistent and non-persistent messages
Guaranteed message delivery that ensures that messages arrive once and only once where required
Transactional and reliable - supporting ACID semantics
Customizable security framework based on JAAS
Fully integrated with JBoss Transactions (formerly known as Arjuna JTA) for full transaction recoverability.
Extensive JMX management interface
Support for most major databases including Oracle, Sybase, MS SQL Server, PostgreSQL and MySQL
HTTP transport to allow use through firewalls that only allow HTTP traffic
SSL transport
Configurable DLQs (Dead Letter Queues) and Expiry Queues
Message statistics: Gives you a rolling historical view of what messages were delivered to what queues and subscriptions
Automatic paging of messages to storage. Allows the use of very large queues - too large to fit in memory at once
"Logical" queues and topics are distributed across the cluster. You can send to a queue or a topic from any node, and receive from any other.
A particular durable subscription can be accessed from any node of the cluster - allowing you to spread processing load from that subscription across the cluster.
Send a message with a replyTo of a temp queue and it can be sent back on any node of the cluster.
Messages are automatically moved between different nodes of the cluster if consumers are faster on one node than another. This can help prevent starvation or build up of messages on particular nodes.
If you want to ensure that the order of messages produced by a producer is the same as is consumed by a consumer then you can set this to true. This works even in the presence of message redistribution.
When a server fails, your sessions continue without exceptions on a new node as if nothing happened. (Fully configurable - If you don't want this you can fall back to exceptions being thrown and manually recreation of connections on another node)
If the node you are connected to fails, you will automatically fail over to another node and will not lose any persistent messages. You can carry on with your session seamlessly where you left off. Once and only once delivery of persistent messages is respected at all times.
JBoss Messaging contains a message bridge component which enables you to bridge messages between any two JMS1.1 destinations on the same or physical separate locations. (E.g. separated by a WAN). This allows you to connect geographically separate clusters, forming huge globally distributed logical queues and topics.
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.
JBoss Messaging does not have wire format compatibility with JBossMQ so it would be necessary to upgrade JBoss MQ clients with JBoss Messaging client jars.
Even if JBoss Messaging deployment descriptors are very similar to JBoss MQ deployment descriptors, they are not 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.
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.
In the installation directory of your JBoss Enterprise Application Platform you will find a set of JBoss Messaging examples located in JBOSS_DIST/doc/examples/jboss-messaging-examples. These examples demonstrate JBoss Messaging in action. Within the JBOSS_DIST/doc/examples/jboss-messaging-examples directory, you will find the following sub-directories:
docs/examples/jboss-messaging-examples/queue
This example demonstrates a simple 'send' and 'receive' to a remote queue using a JMS client.
docs/examples/jboss-messaging-examples/topic
This example demonstrates a simple 'send' and 'receive' to a remote topic using a JMS client.
docs/examples/jboss-messaging-examples/mdb
This example demonstrates the usage of an EJB2.1 MDB with JBoss Messaging.
docs/examples/jboss-messaging-examples/ejb3mdb
This example demonstrates the usage of an EJB3 MDB with JBoss Messaging.
docs/examples/jboss-messaging-examples/stateless
This example demonstrates an EJB2.1 stateless session bean interacting with JBoss Messaging.
docs/examples/jboss-messaging-examples/mdb-failure
This example demonstrates rollback and redelivery occuring with an EJB2.1 MDB.
docs/examples/jboss-messaging-examples/secure-socket
This example demonstrates a JMS client interacting with a JBoss Messaging server using SSL encrypted transport.
docs/examples/jboss-messaging-examples/http
This example demonstrates a JMS client interacting with a JBoss Messaging server tunneling traffic over HTTP protocol.
docs/examples/jboss-messaging-examples/web-service
This example demonstrates JBoss web-service interacting with JBoss Messaging.
docs/examples/jboss-messaging-examples/distributed-queue
This example demonstrates a JMS client interacting with a JBoss Messaging distributed queue - it requires two JBoss Application Server instances to be running.
docs/examples/jboss-messaging-examples/distributed-topic
This example demonstrates a JMS client interacting with a JBoss Messaging distributed topic - it requires two JBoss Application Server instances to be running.
docs/examples/jboss-messaging-examples/stateless-clustered
This example demonstrates a JMS client interacting with a clustered EJB2.1 stateless session bean, which in turn interacts with JBoss Messaging. The example uses HAJNDI to lookup the connection factory. It requires two JBoss Application Server instances to be running.
docs/examples/jboss-messaging-examples/bridge
This example demonstrates the usage of a message bridge. It deploys a message bridge in JBoss Application Server which then proceeds to move messages from a source to a target queue.
To compile the examples, you must have Apache Ant 1.6+ installed in your machine. You can download it from http://ant.apache.org and have it installed in few steps:
Unzip the downloaded file to the directory of your choice.
Create an environment variable called ANT_HOME pointing to the Ant installation directory. You can do this by adding the following line to your .bashrc file (substituting with the actual location of the ant directory on your system):
export ANT_HOME=/home/user/apache-ant-1.7.0
On Windows you do this by opening the Control Panel from the Start Menu, switching it to classic view if necessary, then opening System/Advanced/Environment Variables. Create a new variable, call it ANT_HOME and set it to be the ant directory.
Add $ANT_HOME/bin to the system path to be able to run ant from the command line. You can do this by adding the following line to your .bashrc file:
export PATH=$PATH:$ANT_HOME/bin
On Windows you do this by opening the Control Panel from the Start Menu, switching it to classic view if necessary, then editing the PATH environment variable found in System/Advanced/Environment Variables/System Variables/Path. Add a semicolon and the path to the ant bin directory.
Verify your Ant installation. To do this type ant -version at the command prompt. Your output should look something like this:
Apache Ant version 1.7.0 compiled on December 13 2006
Create an environment variable that points to the installation directory (JBOSS_DIST/jboss-as) and call it JBOSS_HOME. Add $JBOSS_HOME/bin to the system path to be able to run the server from the command line. You can do this by adding the following lines to the .bashrc file in your home directory.
#In this example /home/vrenish/EnterprisePlatform-4.3/jboss-as is the installation directory. export JBOSS_HOME=/home/vrenish/EnterprisePlatform-4.3/jboss-as export PATH=$PATH:$JBOSS_HOME/bin
Create an environment variable called JBOSS_HOME that points to the installation directory, for example: C:\Program Files\EnterprisePlatform-4.3\jboss-as\. In order to run the server from the command line add the bin directory to your path, for example: C:\Program Files\EnterprisePlatform-4.3\jboss-as\bin. To do this, open the Control Panel from the Start Menu, switch to Classic View if necessary, open the System Control Panel applet, select the Advanced Tab, and click on the Environment Variables button.
Make sure you start the JBoss Application server before trying to run the examples. The non clustered examples expect a single JBoss Application Server instance to be running with all the default settings. The clustered examples expect two JBoss Application Server instances to be running with ports settings as per ports-01 and ports-02. For each example, you can always override the default ports it will try to connect to by editing jndi.properties in the particular example's directory.
To run any of the examples inside the JBOSS_DIST/doc/examples/jboss-messaging-examples directory, navigate to the example's folder in a command line prompt, and type ant.
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 these configuration files. In this chapter, we will discuss how to configure various services inside JBoss Messaging, which work together to provide JMS API level services to client applications.
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 messaging-service.xml, remoting-bisocket-service.xml, xxx-persistence-service.xml (where xxx is the name of your database), connection-factories-service.xml and destinations-service.xml.
The AOP client-side and server-side interceptor stacks are configured in aop-messaging-client.xml and aop-messaging-server.xml. 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.
The Server Peer is the heart of the JBoss Messaging JMS facade. The server's configuration, resides in messaging-service.xml configuration file.
All JBoss Messaging services are rooted at the server peer.
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
<mbean code="org.jboss.jms.server.ServerPeer"
name="jboss.messaging:service=ServerPeer"
xmbean-dd="xmdesc/ServerPeer-xmbean.xml">
<!-- 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>
<!-- 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>
<attribute name="EnableMessageCounters">false</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>
-->
<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>
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
We will now discuss the MBean attributes of the ServerPeer MBean.
The unique id of the server peer. Every node you deploy MUST have a unique id. This applies to different nodes that form a cluster as well as nodes that are only linked via a message bridge. The id must be a valid integer.
The default JNDI context to use when binding queues. Defaults to /queue.
The default JNDI context to use when binding topics. Defaults to /topic.
This is the post office that the ServerPeer uses. Normally, you wouldn't have to change this attribute. The post office is responsible for routing messages to queues and maintaining the mapping between addresses and queues.
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.
The DefaultSecurityConfig attribute element should contain one <security> element. The <security> element can contain multiple <role> elements. Each <role> element defines the default access for that particular role.
If the read attribute is true then that role will be able to read (create consumers, receive messaages or browse) destinations by default.
If the write attribute is true then that role will be able to write (create producers or send messages) to destinations by default.
If the create attribute is true then that role will be able to create durable subscriptions on topics by default.
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.
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 10.
This value can also be overridden on a per destination basis.
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.
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
The default value is 0 which means there will be no delay.
Change this if your application could benefit with a delay before redelivery. This value can also be overridden on a per destination basis.
Periodically the server will query each queue to gets its statistics. This is the period.
The default value is 10000 milliseconds.
The maximum number of milliseconds the client will wait for failover to start on the server side when a problem is detected.
The default value is 60000 (one minute).
The maximum number of milliseconds the client will wait for failover to complete on the server side after it has started.
The default value is 300000 (five minutes).
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.
The name of the connection factory to use for pulling messages between nodes.
If you wish to turn off message sucking between queues altogether, but retain failover, then you can ommit this attribute altogether.
If true, then strict JMS ordering is preserved in the cluster. See the cluster configurations section for more details. Default is false.
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.
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.
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.
JBoss Messaging provides statistics for each message counter for each queue.
Set to false to prevent server side failover occurring in a cluster when a node crashes.
This is the persistence manager that the ServerPeer uses. You will not normally need to change this attribute.
This is the JMS user manager that the ServerPeer uses. You will not normally need to change this attribute.
This operation lets you programmatically deploy a queue.
There are two overloaded versions of this operation
If the queue already exists but is undeployed it is deployed. Otherwise it is created and deployed.
The name parameter represents the name of the destination to deploy.
The jndiName 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>.
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.
This operation lets you programmatically undeploy a queue.
The queue is undeployed but is NOT removed from persistent storage.
This operation returns true if the queue was successfull undeployed. otherwise it returns false.
This operation lets you programmatically destroy a queue.
The queue is undeployed and then all its data is destroyed from the database.
Be careful when using this method since it will delete all data for the queue.
This operation returns true if the queue was successfully destroyed. otherwise it returns false.
This operation lets you programmatically deploy a topic.
There are two overloaded versions of this operation.
If the topic already exists but is undeployed it is deployed. Otherwise it is created and deployed.
The name parameter represents the name of the destination to deploy.
The jndiName 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>.
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.
This operation lets you programmatically undeploy a topic.
The queue is undeployed but is NOT removed from persistent storage.
This operation returns true if the topic was successfully undeployed. otherwise it returns false.
This operation lets you programmatically destroy a topic.
The topic is undeployed and then all its data is destroyed from the database.
Be careful when using this method since it will delete all data for the topic.
This operation returns true if the topic was successfully destroyed. otherwise it returns false.
This operation returns message counters in an easy to display HTML format.
This operation enables all message counters for all destinations. Message counters are disabled by default.
This operation disables all message counters for all destinations. Message counters are disabled by default.
Retrieves a list of the Xids for all transactions currently in a prepared state on the node.
The JMS service in the JBoss AS uses relational databases to persist its messages. For improved performance, you should change the JMS service to take advantage of the external database. To do that, you need to replace the file jboss-as/server/production/deploy/jboss-messaging.sar/clustered-hsqldb-persistence-service.xml with a file in jboss-as/docs/examples/jms/ depending on your external database and restart your server.
MySQL: mysql-persistence-service.xml
PostgreSQL: postgresql-persistence-service.xml
Oracle: oracle-persistence-service.xml
Sybase: sybase-persistence-service.xml
MS SQL Server: mssql-persistence-service.xml
For the default and all configurations, replace the files jboss-as/server/default/deploy/jboss-messaging.sar/hsqldb-persistence-service.xml and jboss-as/server/all/deploy/jboss-messaging.sar/clustered-hsqldb-persistence-service.xml respectively.
Also, be aware that by default, the Messaging services relying on a datastore are referencing "java:/DefaultDS" for the datasource. If you are deploying a datasource with a different JNDI name, you need to update all the DataSource attribute in the persistence configuration file. Example data source configurations for each of the popular databases are available in the distribution.
You can configure a JCA datasource using an example from jboss-as/docs/examples/jca and copying to jboss-as/server/. By default JBoss Messaging uses <config-name>/deployDefaultDS.
It is the job of the post office to route messages to their destination(s).
The post office maintains the mappings between addresses to which messages can be sent and their final queues.
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.
The post office also handles the persistence for the mapping of addresses.
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.
The post office configuration is found in the xxx-persistence-service.xml file (where xxx is the name of your database).
Here is an example of a post office configuration:
<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>
<!-- If true then we will automatically detect and reject duplicate messages sent during failover -->
<attribute name="DetectDuplicates">true</attribute>
<!-- The size of the id cache to use when detecting duplicate messages -->
<attribute name="IDCacheSize">500</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>
<!-- Set this to true if you want failover of connections to occur when a node is shut down -->
<attribute name="FailoverOnNodeLeave">false</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>
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.
Set this to true 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 SQLException will be thrown by the JDBC driver and ignored by the Persistence Manager, allowing it to continue.
By default the value of CreateTablesOnStartup attribute is set to true
Set this to true if you wish the post office to detect duplicate messages, that may be sent, when a send is retried on a different node after a server failure.
By default the value of the DetectDuplicates attribute is set to true.
If duplicate detection (See DetectDuplicates) is enabled, then the server will remember the last n message ids sent. This will prevent sending duplicate messages after a failover has occurred. The value of n is determined by this attribute.
By default the value of the IDCacheSize attribute is set to 500.
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.
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.
The maximum time to wait when waiting for the group state to arrive when a node joins a pre-existing cluster.
The default value is 5000 milliseconds.
The maximum time to wait for a reply casting message synchronously.
The default value is 5000 milliseconds.
If this attribute is set to true, when a server node is shut down cleanly, any connections on the node that is shut down, will failover onto another node.
The default value for this is attribute is false.
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.
The default value is 50
JBoss Messaging uses JGroups for all group management. This contains the JGroups stack configuration for the control channel.
The control channel is used for sending request/receiving responses from other nodes in the cluster
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 http://www.jgroups.org or http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups.
JBoss Messaging uses JGroups for all group management. This contains the JGroups stack configuration for the data channel.
The data channel is used for sending sending/receiving messages from other nodes in the cluster and for replicating session data.
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 http://www.jgroups.org or http://wiki.jboss.org/wiki/Wiki.jsp?page=JGroups.
It is the job of the persistence manager to manage all message related persistence.
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.
The configuration of "persistent" services is grouped in a xxx-persistence-service.xml file, where xxx corresponds to the database name. By default, Messaging ships with a hsqldb-persistence-service.xml, which configures the Messaging server to use the in-VM Hypersonic database instance that comes by default with any JBossAS instance.
The default Persistence Manager 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.
The Critique of Hypersonic wiki page outlines some of the well-known issues occuring when using this database.
JBoss Messaging also ships with pre-made Persistence Manager configurations for MySQL, Oracle, PostgreSQL, Sybase and MS SQL Server. The example mysql-persistence-service.xml, ndb-persistence-service.xml, oracle-persistence-service.xml, postgres-persistence-service.xml and sybase-persistence-service.xml and mssql-persistence-service.xml configuration files are available in the examples/config directory of the release bundle.
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.
JBoss Messaging also ships with a 'Null Persistence Manager' config - this can be used when you don't want any persistence at all.
The default Hypersonic persistence configuration file is listed below:
<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>
<attribute name="UseNDBFailoverStrategy">true</attribute>
</mbean>
Set this to true 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 SQLException will be thrown by the JDBC driver and ignored by the Persistence Manager, allowing it to continue.
By default the value of CreateTablesOnStartup attribute is set to true
Set this to true if the database supports JDBC batch updates. The JDBC Persistence Manager will then group multiple database updates in batches to aid performance.
By default the value of UsingBatchUpdates attribute is set to false
Set this to true 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().
By default the value of UsingBinaryStream attribute is set to true
Certain version of Sybase are known to truncate blobs if they have trailing zeros. To prevent this if this attribute is set to true 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.
By default the value of UsingTrailingByte attribute is set to false
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.
By default the value of SupportsBlobOnSelect attribute is set to true
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.
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.
By default the value of MaxParams attribute is set to 100
When running in a clustered database environment it is possible that some databases, MySQL for instance, can fail during the commit of a database transaction. If the database node dies while committing then the final state of the transaction is unknown. If the attribute UseNDBFailoverStrategy is set to true and the above happens then the SQL statement will be re-executed. However any further error is ignored because an assumption is made that the error is due to the previous transaction being committed successfully.
By default the value of the attribute UseNDBFailoverStrategy is set to false.
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
Here is an example JMSUserManager configuration
<mbean code="org.jboss.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>
Set this to true 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 SQLException will be thrown by the JDBC driver and ignored by the Persistence Manager, allowing it to continue.
By default the value of CreateTablesOnStartup attribute is set to true
Set this to true if the database supports JDBC batch updates. The JDBC Persistence Manager will then group multiple database updates in batches to aid performance.
By default the value of UsingBatchUpdates attribute is set to false
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.
Default user and role data can also be specified here. Any data to be inserted must be specified with property names starting with POPULATE.TABLES as in the above example.
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 destinations-service.xml. A section of this file is listed below:
<!--
The Default Dead Letter Queue. This destination is a dependency of an EJB MDB container.
-->
<mbean code="org.jboss.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>
<mbean code="org.jboss.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>
<mbean code="org.jboss.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>
<m