"bander" wrote : | My test case does not know about the different nodes - it has simply requested multiple connections from the connection factory. It sounds like I'm not using the correct JBoss configuration for my test case. In the scenario where the messaging client had connected consumers to one node and producers to another node we would want JBoss Messaging to ensure the messages on the queues were distributed to the nodes with active consumers. | Basically JBM clustering needs to be tuned according to your application topology. Different types of applications have different requirements for load balancing and redistribution. So first you need to determine what kind of application you have then tune based on that. The most common use of clustering is a bank of servers with the same MDBs on each node. In such a case moving messages from one node to another is not required. It always makes sense to favour the local node. There are other topologies where there are more consumers on one node than another or consumers with different throughput on different nodes. In these cases redistribution can be configured. There is a chapter in the user guide on this which I am going to expand upon in the future. anonymous wrote : | Ok - this is the more critical issue for us. I can break it consistently and within a very short time. For our testing we're using WinXP and JVM 1.4.2-b28. Which JVM are you using? Have you changed any of the configuration defaults? | I am using WinXP and JDK1.5 and all the default settings. The cruisecontrol run is using Linux on multi processor intel. anonymous wrote : | Obviously. I what I meant was that after shutting both nodes down for a period and then restarting one the test case should reconnect and start dispatching/receiving again. Shutting down both servers seemed to cause problems in the client i.e. it failed to detect that one of the nodes had been restarted. The cluster requires at least one node to be up to remain a cluster. If all nodes fail then the clients will fail. If you're expecting the client to keep on retrying if the *entire* cluster disappears in the hope it will eventually come up, then this is currently not supported. I'm not sure which other JMS providers support this either - JBoss MQ certainly doesn't. Typically you would design the cluster with enough nodes such that the probability of all servers simultaneously failing is vanishingly small. Client retrying is not something we normally consider under the banner of "clustering" - but we have a task for it which is due to be complete in 1.2.1. This feature would be useful in scenarios such as ATM machines or POS terminals where the connection to the "main office" is unstable. If you feel this is an important feature then you can vote for and bump the priority of the feature request. Right now we have a message bridge which is resilient to failure so you can always use this to bridge your "unstable" connection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4026473#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...