How do you start the two nodes?
What profile (default/all/...) do you use or have copied?
Thanks for your reply.
They are both all profile.
first node start script:
run.sh -c all -b 0.0.0.0 -g FECluster -Djboss.messaging.ServerPeerID=1
second node start script
run.sh -c all1 -Djboss.service.binding.set=ports-02 -b 0.0.0.0 -g FECluster -Djboss.messaging.ServerPeerID=2
Make sure you have the right value for ServerPeerID in /opt/pvo/conf/jboss/all.pvo/deploy/messaging/messaging-service.xml
<!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer -->
I set this value passing the paramater -Djboss.messaging.ServerPeerID to the run.sh script.
So I think that this is not the issue...
Check whether JBoss Messaging is in cluster or not. For this I think you can checl "PostOffice".
Browse "jboss.messaging:service=PostOffice" MBean, you should see (at the bottom of attributees list) "NodeIDView" attribute will have values as [1,2].
These are the ServerPeerID's that you are sending in start up scripts.
If JBoss Messaging is in cluster. Try to stop MDB processing from the node in which your JMS client is present, then push the message and check whether message is processed by another node or not.
NodeIDView is [1,2], so two nodes are in cluster.
I have tried to stop the first node (where JMS client is...) and after that the second node process messages.... It seems that messages are processed only by local MDB. But it's strange because, if I understand well, the cluster is implemented at the queue level.
To complete actual configuration: messaging persistence is on a shared MySql database.
Do you try to you use 'ClusteredConnectionFactory' as you mentionend in your initial post?
I use JmsXA, but I need XA Tx and use Topics so I don't check loadbalancing.
Why do you lookup instead of use injection? Do you try this?
Dieter, I use lookup because the JMS client is not a JEE component, is a simple Quartz job.
Yes, a tried ClusteredConnectionFactory, but it's another approach... With ClusteredConnectionFactory is the Connection clustered, not the queue.
Generally this approach is used when JMS queue is remote (and clustered), but this is not the case. Here I want a clustered queue, with messages distributed on all nodes. However when I used a ClusteredConnectionFactory it worked for a while, but then the client couldn't route the message and I receive this exception:
javax.jms.JMSException: Failed to route Reference:RELIABLE to timsocialSlowUpdateProfileQueue
its quite long time but maybe somoene found the solution.
I have the same problem as Valerio had. All the settings and jmx-console outputs are same for me as described above. Queue still behaves as non-clustered (on Jboss 5.1).