"s.gasse" wrote : Hi, | | thanks for the reply. The problem is somehow solved now, since our system uses message selectors and we found out, that this is actually not supported by a clustered JBM implementation. Message selectors only work on the *local" destination. This has been discussed many times over the years, but in general multiple message selectors on queues is considered an anti-pattern? Why? Because you need to scan the entire queue to see if one matches every time you deliver a message. ==> slow! On a cluster that's compounded even further. You'd have to scan every message on every server to see if one matches. ==> Horrible performance. BTW this is not JBM specific. You'll find the same issues with pretty much any messaging system. If you're effectively using selectors to "select" messages from a "table", then you're basically using the messaging system like a database, and that's not what messaging systems are for. If you wish that table then you're basically expecting the messaging system to behave like a clustered database, which is not what it is designed to do! Perhaps something like Oracle RAC would be a better fit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197317#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...