I think that's a very wise choice to stay on 4.2.3. One point to note though about the load balancer in JBM 1.4.0 sp3. There are two different components that load balance. 1. Round Robin connection when using the clustered connection factory. What this means is that if you are using the clustered connection factory, each connection you request you will get a connection to a different server. Messages being consumed or being added will go to that server. 2. Suckers - the suckers pull messages from one machine to the other to try to balance the load. So in a clustered queue, one machine will pull from the other. But it will only pull messages if it's queue is empty. So the queue has to be completely empty in order to start to look for messages elsewhere. Cautions and Warnings about using a clustered queue: 1. Selectors don't work clusterwide. This means that while you may add a selector, it will only select from the server that it is connected by. If you have a consumer that has a selector and the server queue that it is connected to has messages, but doesn't match the selector, no load balancing will take place. Because there's still a message in the queue, it just doesn't match your selector. It's important to understand that selectors don't work in a clustered scenerio, because they are the solution to many jms antipatterns. 2. Queue Browse doesn't work clusterwide. Since this is a peer to peer server setup, there is no way to browse the entire queue, because a small piece of that queue is on each server. I suppose we could write something that would gather the queue contents from each machine and send them back, but by the time they got back the data would be stale. A clustered queue-browse is just not feasible with the current setup. Hopefully you won't fall into any of these gotyas. Jay:) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179370#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...