Added: incubator/activemq/site/Message+Groups URL: http://svn.apache.org/viewcvs/incubator/activemq/site/Message%2BGroups?rev=374430&view=auto ============================================================================== --- incubator/activemq/site/Message+Groups (added) +++ incubator/activemq/site/Message+Groups Thu Feb 2 08:31:10 2006 @@ -0,0 +1,247 @@ + + + + + + + + ActiveMQ - Message Groups + + + + + + + + + + + + + + + +
+ + + + + + +
+

Overview

+ +

Community

+ +

Using ActiveMQ

+ +

Features

+ +

Connectivitiy

+ +

Utilities

+ +

External Tools

+ +

Related Projects

+ +

Support

+ +

Developers

+ +

Tools we use

+ +

Feeds

+ + + + + + + + + +
+
+
+ Site +
+ + + News +
+
+ +
+ + + + + +
+ Message Groups + + +
+
+ + +
+
+

Message Groups rock! They are an enhancement to the Exclusive Consumer feature to provide

+
    +
  • guarranteed ordering of the processing of related messages across a single queue
  • +
  • load balancing of the processing of messages across multiple consumers
  • +
  • high availability / auto-failover to other consumers if a JVM goes down
  • +
+

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.

+

Example

+

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.

+

Impliciations

+

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

+
    +
  • partioning the traffic
  • +
  • load balancing of message groups across consumers
  • +
  • auto-failover of groups to different consumers as consumers come and go
  • +
+

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.

+
+
+ +   +