In most cases, allowing selectors on a JMS queue is an anti-pattern since it can cause the queue to be scanned frequently - i.e. give poor performance. Also JMS selectors only work on the *local* queue - i.e. each clustered queue is made up of n local partial queues - one on each node. If your consumer has a selector then that does not determine whether or not messages are pulled to or from that node. This can result in messages being pulled from one node to another, where they won't be consumed because the selector doesn't match. Making message redistribution cluster aware would be extremely difficult. Think about it. Imagine messages are pulled to one node based on the selectors on that node, then the consumer changes on that node, and another one starts on another node that matches. We would have to maintain a global view of what selectors were on each node and messages would be shifted en-masse back and forth every time a selector changed! If you want to do clustered request-response, then you could either a) Use a *topic* with selectors. (I general if you ever see yourself using selectors with queues it's always a good idea to see if you can refactor to use topics). b) Use a temporary request/response queue - in this case you don't need selectors since the response queue is only used by you. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126940#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...