Actually I think there is a solution to this problem which allows grouping and filters to work together, but it requires a rethink of the way message grouping is currently implemented. The problem is, as already stated, that, with the way the grouping round robin distributor currently works, the message would need to be provided at peek() time in order to determine which consumer to choose, but the message is not known at that time. However, in principle it should be possible to implement the behaviour that if a consumer has both a filter and a message group it should only receive messages which match both the filter and the message group, there's nothing impossible about implementing that. To do this, we would have a Distributor that *always round robins* (i.e we don't have a grouping round robin distributor at all). This makes it easy to have a peek() method on it that does not need a message to be passed in. Once the queue has the consumer it looks up the iterator for that consumer (if any) and gets the next message using that iterator. It passes that message to the consumer which either accepts or rejects it depending on its filter and what message group (if any) it is in. The queue then asks the distributor for the next consumer gets the iterator for that consumer and the process repeats. In this implementation its the *consumer* that would know what message groups it is handling, i.e. the grouping logic moves from the grouping round robin distributor to the server consumer. Each server consumer will only accept a message if both it's filter matches and the message's group id is in the shared set for itself. Every grouping server consumer would need access to a shared map of group id-->consumer. If a consumer receives a message with a group id and no other consumer is already handling it, then it can associate itself to that group id in the map. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241513#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...