Scaleability of JMS Clients Receiving Messages

Question

How do you scale the receipt of messages in a JMS client for messages from the same topic?
Given a topic, I would like to enable concurrent receipt and processing of messages by many concurrent listeners where a single message is only consumed once by any of the listeners. Even more, I would like to scale by having many clients with possibly many listeners servicing the same topic where a single message is only consumed/processed once.
However, based on the documentation (see below) it appears sessions only enable a single thread of execution to be simultaneously running servicing incoming messages one at a time! And adding subscribers implies the delivery of a single message to each subscriber creating duplicate processing of the same message.
Quote from JMS Tutorial: "The session used to create the message consumer serializes the execution of all message listeners registered with the session. At any time, only one of the session's message listeners is running."

Answer 1

Hi vincegeorge,
To be able to have several consumers actively using message listeners concurrently you could create each consumer on a different session. This would get around your problem of concurrent receipt and processing of messages when using message listeners.
The second problem, ensuring that each message is received by only one TopicSubscriber is much more difficult. As each subscriber will receive every message that is sent to the particular topic then each subscriber will be sent a copy of that message. The only exception to this rule is if you have set a "message selector" for the consumer. If you knew exactly which subscribers were active at the publisher end then you could set a property on the message, e.g. SubscriberID=1, on the message and then each subscriber could set a message selector to say that they only wished to receive messages with the property SubscriberID set to their particular number. To notify the publisher which subscribers are active you could have a special destination that contains heartbeat messages informing everyone of their subscriberID.
However, is it possible instead though that you could use a queue. This would be much easier to code (no message selector and no need to keep everyone informed of which subscriberID's are available) as the queue would ensure that only one receiver ever consumed the message.
Hope this helps a little,
Tom Jenkinson
Arjuna Technologies Limited