Message Groups rock! They are an enhancement to the Exclusive Consumer feature to provide
So logically Message Groups are kinda like a parallel Exclusive Consumer. Rather than all messages going to a single consumer, the standard JMS header JMSXGroupID is used to define which message group the message belongs to. The Message Group feature then ensures that all messages for the same message group will be sent to the same JMS consumer - while that consumer stays alive. As soon as the consumer dies another will be chosen.
Another way of explaining Message Groups is that it provides sticky load balancing of messages across consumers; where the JMSXGroupID is kinda like a HTTP session ID or cookie value and the message broker is acting like a HTTP load balancer.
Lets say we are doing some kind of order matching system where people are buying and selling things (stocks, shares, placing online bets, whatever).
You want to have consumers who match bids and offers for different items (stocks / bets) so they want to keep in RAM for performance a sub-set of the data set.
So set the JMSXGroupID to be MSFT, IBM, SUNW and so forth to use the stock symbol to define the message group. (It can be any string whatsoever; maybe combining trading book, trading exchange, date and so forth - the more specific the group ID, the more concurrent you can run).
So assuming we are buying and selling MSFT, IBM, SUNW shares; the Message Groups feature guarrentees that all the MSFT messages will be processed in order by the same consumer; ditto for IBM and SUNW.
When a message is being dispatched to a consumer, the JMSXGroupID is checked. If one is present then the broker checks to see if a consumer owns that message group. (Since there could be a massive number of individual message groups we use hash buckets rather than the actual JMSXGroupID string).
If no consumer is associated with a message group a consumer is chosen. That JMS MessageConsumer will receive all further messages with the same JMSXGroupID value until
Note: like message selector matching, grouping based on JMSXGroupID occurs before dispatch on messages in memory. With the default maxPageSize setting, large backlogs of messages destined for one group they can block receipt of messages to other groups if they don't all fit in memory. You can change the default maxPageSize setting for destinations as follows:
You just need to change your JMS producers to fill in the JMSXGroupID message header with some String value of your choice. e.g.
You generally don't need to close a message group; just keep using it. However if you really do want to close a group you can add a negative sequence number.
This then closes the message group so if another message is sent in the future with the same message group ID it will be reassigned to a new consumer.
Message Groups mean you get the power of grid processing of messages across a cluster of consumers with reliability, auto-failover, load balancing but you can also order the processing of messages too. So its the best of both worlds.
However using the above example, what Message Groups actually do is to partition your work load across consumers using a user defineable partition strategy - the JMSXGroupID value.
The neat thing about this is that you can do neat things like use lots of RAM caching; keep the order for MSFT in RAM in the MSFT consumer; keep the IBM orders in RAM in the IBM consumer - since the message broker is partitioning for you, you do not have to rely on a distributed cache with inter-cache synchronisation and locking to take advantage of caching.
The great thing is - to the application developer, it looks like a simple 1 consumer world where you process messages and do your job; leaving the broker to do all the hard stuff for you
In summary; if ordering or per-message caching and synchronization are in any way important to you then we highly recommend you use message groups to partition your traffic.
In 4.1 onwards of ActiveMQ there is support for a new boolean header called JMSXGroupFirstForConsumer which will be set on the first message which is sent to a consumer for a particular message group.
If the JMS connection is using failover: and a temporary network error occurs so that the connection disconnects from the broker and reconnects some time later, a new consumer instance will be created under the covers of the JMS client leading to the possibility of another message with this header being set for the same message group.
So you can do code like...
To flush caches to ensure consistent state when faced with network errors.
If you have existing messages in the broker and add consumers at a later stage, it is a good idea to delay message dispatch start until all consumers are present (or at least to give enough time for them to subscribe). If you don't do that the first consumer will probably acquire all message groups and all messages will be dispatched to it. You can achieve this by using consumersBeforeDispatchStarts and timeBeforeDispatchStarts destination policies.
Here's the example of the destination policy that delays dispatch for 200ms
The following code snippet shows how to wait for two consumers (or two seconds) before dispatch starts
As the appropriate test case shows, adding a small time pause before dispatching or setting a minimum consumer number, ensures equal message group distribution.