JBoss Messaging HA Singleton Configuration
JBoss MQ was originally created as a standalone single server messaging system. With JBoss MQ only one node in the cluster can be active at any one time.
Failover for JBoss MQ is implemented by deploying JBoss MQ in the deploy-hasingleton directory of the all configuration.
The application server will then ensure only one instance of JBoss MQ is running in the cluster at any one time.
With JBoss Messaging all nodes in the cluster can host active JMS servers concurrently, so for most use cases there is no need for HA Singleton functionality.
However, there is one case when you may need an old style HA Singleton approach - this is when you have a queue and you wish to ensure that messages are consumed from that queue in strict sequential order by a single consumer - e.g. using the Singleton MDB configuration.
Currently this is not supported natively by JBoss Messaging, but you can get the same effect by running JBoss Messaging as a HA Singleton too!
In effect JBoss Messaging will behave as JBoss MQ in this configuration, with respect to failover and there will only ever be one active JBoss Messaging node in the cluster at any one time.
When running this way you will lose other benefits of JBoss Messaging like automatic failover and distributed destinations.
To deploy JBoss Messaging as a HA Singleton, follow these steps:
JBoss 4.x
On each node move the jboss-messaging.sar directory and all sub directories from all/deploy to all/deploy-hasingleton
On each node set the attribute "Clustered" to false, in the file jboss-messaging.sar/xxx-persistence-service.xml (where xxx is the name of your database).
On each node ensure that each JBoss Messaging server has the same server peer id. Note that this differs from a normal JBoss Messaging clustered install where each node has a different node id.
Use HA-JNDI from the client to lookup your connection factories and destinations, exactly as you would with JBoss MQ.
Do not use any clustered connection factories from the client.
For failover, you will need to code your own ExceptionListener, and close, re-lookup the connection factory and recreate the connections when failure is detected, exactly as you would with JBoss MQ.
JBoss 5.1.0.GA
On each node move the messaging directory all/deploy (it just contains XML files) to all/deploy-hasingleton/messaging
do not move the jms-ds.xml file. Leave that as the only file in all/deploy/messaging. This is because each node in the cluster will need its own DefaultJMSProvider
- change deploy/messaging/jms-ds.xml to use HA-JNDI (modelled off JBoss 4.2.3/server/all/deploy/jms/hajndi-jms-ds.xml):
<attribute name="FactoryRef">XAConnectionFactory</attribute>
<attribute name="QueueFactoryRef">XAConnectionFactory</attribute>
<attribute name="TopicFactoryRef">XAConnectionFactory</attribute>
<attribute name="Properties">
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=${jboss.bind.address:localhost}:1100
jnp.disableDiscovery=false
jnp.partitionName=${jboss.partition.name:DefaultPartition}
jnp.discoveryGroup=${jboss.partition.udpGroup:230.0.0.4}
jnp.discoveryPort=1102
jnp.discoveryTTL=16
jnp.discoveryTimeout=5000
jnp.maxRetries=1
</attribute> - as a hack, remove the <depends>jboss.messaging:service=ServerPeer</depends> from the JmsXA definition in jms-ds.xml. Only the singleton node in the cluster will have a ServerPeer, because it is defined in deploy-hasingleton/messaging/messaging-service.xml
On each node set the attribute "Clustered" to false, in the file messaging/xxx-persistence-service.xml (where xxx is the name of your database).
On each node ensure that each JBoss Messaging server has the same server peer id. Note that this differs from a normal JBoss Messaging clustered install where each node has a different node id.
Use HA-JNDI from the client to lookup your connection factories and destinations, exactly as you would with JBoss MQ.
in other words, use jnp://localhost:1100/queue/foo in jboss.xml
- as a hack, remove the dependancy on the DLQ by adding (to each queue in jboss.xml):
<activation-config>
<activation-config-property>
<activation-config-property-name>useDLQ</activation-config-property-name>
<activation-config-property-value>false</activation-config-property-value>
</activation-config-property>
</activation-config> Do not use any clustered connection factories from the client.
For failover, you will need to code your own ExceptionListener, and close, re-lookup the connection factory and recreate the connections when failure is detected, exactly as you would with JBoss MQ.
- Be aware that, by default, each node in the cluster will grab the first 150 messages in the queue and move them to a local buffer. Therefore, it may appear that some nodes are 'starving' while another node is struggling processing its 150 messages. You can reduce this default by setting PrefetchSize in deploy-hasingleton/messaging/connection-factories-service.xml. For example <attribute name="PrefetchSize">1</attribute>
Comments