After a pretty diligent search, I have reached the conclusion that HAJMS Clustering on
JBoss 4.2.X is broken. I posted to the Forum, but haven't gotten a response back yet. On the other hand I find it hard to believe that such a basic part of the release could be broken. (After many years of extensive research I have discovered that most of my difficulties really are my fault
)
So I'll ask the question here has anyone gotten the HAJMS on JBoss to work when there is more than one node in the cluster?
Here is a link to my post, but I'll repeat it here for convenience.
JBoss Forumn post ##################################################################
my post
##################################################################
I am pretty confident that this is a bug, but it is possible that I have missed something. In brief, the the problem is that no node will act as the MasterNode if there is more than 1 node in the cluster.
Here's what I have run into: After configuring the nodes to be identical as per the documentation, the first node to come up will deploy the queues defined in the deploy-hasingleton/jms directory, but as soon as the second node of the cluster comes up the original node receives a stop from the BarrierController, and un-deploys the queues. The second node does not start up the queues neither do subsequent nodes in the cluster. When you stop all of the nodes in the cluster except 1, that node (it doesn't matter which) will bring back the queues.
The exact same configuration under 4.0.5 works as expected.
This behavior is easy to replicate, just install 2 virgin copies of Jboss on separate nodes. Then bring up the first node with the all configuration (run.bat -c all). Note that is elected the Master
2007-09-24 06:48:09,718 DEBUG [org.jboss.ha.singleton.HASingletonController] partitionTopologyChanged, isElectedNewMaster=true, isMasterNode=false, viewID=-35945124
2007-09-24 06:48:09,718 DEBUG [org.jboss.ha.singleton.HASingletonController] startNewMaster, isMasterNode=false
2007-09-24 06:48:09,718 DEBUG [org.jboss.ha.singleton.HASingletonController] startSingleton() : elected for master singleton node
2007-09-24 06:48:09,718 DEBUG [org.jboss.ha.singleton.HASingletonController] Calling operation: deploy(file:/C:/JBoss/jboss-4.2.1.GA/server/all//deploy-hasingleton), on target: 'jboss.system:service=MainDeployer'
? it then created the queues for example
2007-09-24 06:48:10,484 DEBUG [org.jboss.system.ServiceCreator] About to create bean: jboss.mq.destination:service=Queue,name=A with code: org.jboss.mq.server.jmx.Queue
2007-09-24 06:48:10,499 DEBUG [org.jboss.system.ServiceCreator] Created bean: jboss.mq.destination:service=Queue,name=A
2007-09-24 06:48:10,499 DEBUG [org.jboss.system.ServiceController] recording that jboss.mq.destination:service=Queue,name=A depends on jboss.mq:service=DestinationManager
2007-09-24 06:48:10,499 DEBUG [org.jboss.system.ServiceConfigurator] considering DestinationManager with object name jboss.mq:service=DestinationManager
? now bring up the second node. The log on the original node records the following:
2007-09-24 07:37:55,512 INFO [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.DefaultPartition] New cluster view for partition DefaultPartition (id: 1, delta: 1) : [127.0.0.1:1099, 127.0.0.1:1099]
2007-09-24 07:37:55,527 DEBUG [org.jboss.ha.framework.interfaces.HAPartition.DefaultPartition] membership changed from 1 to 2
? followed by
2007-09-24 07:37:56,840 DEBUG [org.jboss.system.BarrierController] Saw 'stop' handback, stopping barrier
2007-09-24 07:37:56,840 DEBUG [org.jboss.system.ServiceController] stopping service: jboss.ha:service=HASingletonDeployer,type=Barrier
2007-09-24 07:37:56,840 DEBUG [org.jboss.system.ServiceController] stopping dependent services for: jboss.ha:service=HASingletonDeployer,type=Barrier dependent services are: []
? and by
2007-09-24 07:37:56,855 DEBUG [org.jboss.system.ServiceController] stopping service: jboss.mq.destination:service=Queue,name=A
2007-09-24 07:37:56,855 DEBUG [org.jboss.system.ServiceController] stopping dependent services for: jboss.mq.destination:service=Queue,name=A dependent services are: []
2007-09-24 07:37:56,855 DEBUG [org.jboss.mq.server.jmx.Queue.A] Stopping jboss.mq.destination:service=Queue,name=A
2007-09-24 07:37:56,855 INFO [org.jboss.mq.server.jmx.Queue.A] Unbinding JNDI name: queue/A
2007-09-24 07:37:56,871 DEBUG [org.jboss.mq.server.JMSDestinationManager] Closing destination QUEUE.A
2007-09-24 07:37:56,871 DEBUG [org.jboss.mq.server.jmx.Queue.A] Stopped jboss.mq.destination:service=Queue,name=A
--------------------------------------------------------------------------------
I thought that the problem could be related to the org.jboss.ha.singleton.HASingletonElectionPolicy feature which was back ported from 5.0,
see:
http://jira.jboss.com/jira/browse/JBAS-3636 This attribute shows up under the MBean attributes of org.jboss.ha.singleton.HASingletonController from the JMX console, but despite showing the attribute as read / write, you can not change the value. Attempts to set the the value in the deploy/deploy-hasingleton-service.xml file result in a property editor exception.
There is some method that I am not aware of that they have used to
test this functionality out in JBoss' test suit, (for example
http://www.ohloh.net/projects/480/contributors/26897/commits/6569686 )
but I could not figure out how to try it out.
