A queue may have multiple receivers attached to it for the purpose of distributing the workload of message processing. The JMS specification states that this capability must be implemented by a JMS provider, although it does not define the rules for how the messages are distributed among consumers. A sender could use this feature to distribute messages to multiple instances of an application, each of which would provide its own receiver.
When multiple receivers are attached to a queue, each message in the queue is delivered to one receiver. The absolute order of messages cannot be guaranteed, since one receiver may process messages faster than another. From the receiver's perspective, the messages it consumes should be in relative order; messages delivered to the queue earlier are consumed first. However, if a message needs to be redelivered due to an acknowledgment failure, it is possible that it could be delivered to another receiver. The other receiver may have already processed more recently delivered messages, which would place the redelivered message out of the original order.
If you would like to see multiple recipients in action, try starting
two instances of QWholesaler and three or more
instances of QRetailer, each in a separate command
window:
java chap5.B2B.QWholesaler localhost WHOLESALER1passwordjava chap5.B2B.QWholesaler localhost WHOLESALER2passwordjava chap5.B2B.QRetailer localhost RETAILER1passwordjava chap5.B2B.QRetailer localhost RETAILER2passwordjava chap5.B2B.QRetailer localhost RETAILER3password
In the command window for one of the QWholesaler
applications, type the following command:
Surfboards, 999.99, 499.99
Upon hitting the enter key, each instance of
QRetailer will get the price quote, and respond
with a "Buy" order. If you have three
QRetailers up and running, you should see two of
the messages going to one of the QWholesalers, and
one going to the other.
Note
If you don't see this behavior, load balancing may not be broken. It may mean that vendor-specific queue settings are preventing load balancing; you may need to send more than three messages simultaneously to populate the queue enough to cause the messages to be delivered to more than one consumer. For example, in SonicMQ there is a configurable pre-fetch count that determines how many messages may be batched together as they are delivered to a consumer. The default is three messages, so the messages get delivered to each consumer three at a time. The SonicMQ version of these samples has some code that sets the value to one, which makes load balancing work properly with only three clients:
... qReceiver.setPrefetchThreshold(0); qReceiver.setPrefetchCount(1); ...
It is likely that other vendors have the same kind of optimization, so you should check that possibility if you are using a vendor other than SonicMQ and don't see the proper behavior.