The answer really is no. Because JBoss mq is running as a singleton, it means that there's only one instance of mq running in the cluster. So lets say you have machine A, B, and C and A is the master. A will be the only one in the cluster running jboss mq. The rest of the machines have MDBs that connect to A and listen for messages. When your servlet sends a message to the ONE MASTER server(which is the only one running MQ), one of the MDBs on one of the servers will pick it up. Here's the options I see for you... 1. Move over to JBossMessaging. http://www.jboss.org/jbossmessaging/ It already solves your problem. In JBM, the messages are load balanced, but will be picked up by consumers on the local machine first. This solves the behavior problem. 2. Filter your messages by correlation id Set the correlation id or something else in the message your servlet generates, something that you can use a message selector on in the ejb. So lets say that you are using the ip address(or something that identifies that node). You set the correlation id in the message that your servlet sends and then you set a selector that only selects that correlation id. Since the servlet and the ejb are on the same node, you should be able to set an environment variable or use something that's already in the environment that is distinct to that node for the correlation id. 3. I have seen poeple run JBossMQ locally(in the deploy directory) and also as a HASingleton(net result is that two JBossMQ services run). Then the messages that they want consumed by the cluster, they send to the singleton instance, and the ones they want consumed locally, they send to the local instance. I will tell you that it is a configuration and code nightmare though. I though I would bring it up, in case you were considering it. I would not recommend this approach, but others have successfully done it. Personally, If you are in development, I'd move to JBM. JBossMQ is currently in maintenance and is going away in JBoss 5.x. I would start to make the move over to JBoss Messaging now. I'm not saying that there will be an easy migration path from JBM 1.4.0SP3 to JBM 2.0(included in jboss 5.x), but it will be easier as far as design. If you make design decisions based on a singleton messaging system, you may have to go back and undo those design decisions later. Hope this helps, Jay:) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4178811#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...