Chapter 6. JBoss Messaging Clustering Configuration

JBoss Messaging clustering should work out of the box in most cases with no configuration changes. It is however crucial that every node is assigned a unique server id, as specified in the installation guide.

Every node deployed must have a unique id, including those in a particular LAN cluster, and also those only linked by mesage bridges.

Note

Ensure the ServerPeerID MBean attribute value in messaging-service.xml is unique for each node on the cluster. The ServerPeerID value must be a valid integer.

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.

JBoss Messaging balances messages between nodes, catering for faster or slower consumers to efficiently balance processing load across the cluster.

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

JBoss Messaging also supports clustered temporary topics and queues. All temporary topics and queues will be clustered if the post office is clustered

If you don't want your nodes to participate in a cluster, or only have one non clustered server you can set the clustered attribute on the postoffice to false

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

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

Warning

For a clustered installation it is mandatory that a shared database is available to all nodes in the cluster. The default JBoss AS uses HSQLDB for its database which is a local shared database. Therefore in order to use clustering you must replace this with a different shared database. If the database is not replaced then clustering will not work.

If you want to run multiple JBoss Messaging nodes on the same box using the same IP address, e.g. for development purposes, then you can use the ServiceBindingManager to do this as follows:

Uncomment binding manager service from $JBOSS_CONFIG/conf/jboss-service.xml
Specify the desired port rage (e.g. ports-01, ports-02... etc)

Look at $JBOSS_HOME/docs/examples/binding-manager/sample-bindings.xml. On each port range, JBoss Remoting configuration should look like:

      <service-config name="jboss.messaging:service=Connector,transport=bisocket"
                      delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
         <delegate-config>
            <attribute name="Configuration"><![CDATA[
	   <config>
            <invoker transport="bisocket">
               <attribute name="marshaller" isParam="true">
                  org.jboss.jms.wireformat.JMSWireFormat
               </attribute>
               <attribute name="unmarshaller" isParam="true">
                  org.jboss.jms.wireformat.JMSWireFormat
               </attribute>
               <attribute name="dataType" isParam="true">jms</attribute>
               <attribute name="socket.check_connection" isParam="true">false</attribute>
               <attribute name="timeout" isParam="true">0</attribute>
               <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
               <attribute name="serverBindPort">4657</attribute>
               <attribute name="leasePeriod">10000</attribute>
               <attribute name="clientSocketClass" isParam="true">
                  org.jboss.jms.client.remoting.ClientSocketWrapper
               </attribute>
               <attribute name="serverSocketClass">
                  org.jboss.jms.server.remoting.ServerSocketWrapper
               </attribute>
               <attribute name="numberOfRetries" isParam="true">1</attribute>
               <attribute name="numberOfCallRetries" isParam="true">1</attribute>
               <attribute name="clientMaxPoolSize" isParam="true">50</attribute>
            </invoker>
            <handlers>
               <handler subsystem="JMS">
                  org.jboss.jms.server.remoting.JMSServerInvocationHandler
               </handler>
            </handlers>
         </config>
            ]]></attribute>
         </delegate-config>
         <binding port="4657"/>
      </service-config>

Warning

You must ensure that the config (like above) is identical to that in remoting-bisocket-service.xml With the exception of the actual serverBindPort which clearly must be different for each ports range. Please note that the default JBoss Messaging service binding manager bindings in sample-bindings.xml shipped with JBAS 4.2.0 is out of date and you will need to copy the config from remoting-bisocket-service.xml

You should ensure that each node is configured to use a different ports range.