All queues, clustered and regular ones, are automatically registered in JNDI. Starting with SwiftMQ 7.0.0, a JNDI alias is automatically created as well. Say, there is a clustered queue "cqueue" defined on router1, a JNDI lookup can be done with its fully qualified queue name:
Queue queue = (Queue)ctx.lookup("cqueue@router1");
But also with the JNDI alias:
Queue queue = (Queue)ctx.lookup("cqueue");
It is always recommended to use the JNDI alias for lookup to keep the application code clean of router dependencies.
To receive messages from a clustered queue, the consumer can be created either on the clustered queue or on one of its linked physical queues. With a clustered queue "cqueue" and 2 physical queues "c1" and "c2", the consumer can be created this way:
// Create consumer on the clustered queue
Queue queue = (Queue)ctx.lookup("cqueue");
QueueReceiver receiver = session.createReceiver(queue);
Or this way:
// Create consumer on linked physical queue c1@router1
Queue queue = (Queue)ctx.lookup("c1");
QueueReceiver receiver = session.createReceiver(queue);
If the consumer is created on the clustered queue ("cqueue"), it will be round-robin attached to the next linked physical queue. To let SwiftMQ chose the linked physical queue has some advantages. See "Local Clustering" in the section below.
Due to performance reasons, consumers with message selectors are not respected from the dispatch policy of clustered queues. It is therefore not recommended to use message selector in conjunction with clustered queues.
Multiple consumers on a single physical queue are sometimes used to increase throughput. From the JMS application point of view this approach might be reasonable so one might get more throughput. However, from the SwiftMQ Router point of view this is sub-optimal because all consumers are competing on messages on this single queue which adds synchronization overhead.
With clustered queues there is a new way of "Local Clustering". On the local router we just define a clustered queue and as many linked physical queues as we have concurrent queue consumers. The producers send to the clustered queue and the consumers are created on the clustered queue as well. The latter leads to a round-robin assignment of linked physical queues to consumers so that every concurrent consumer has its own physical input queue. Messages are distributed during send and not during receive so there is no competition at the receiver queue which eliminates synchronization.
So whenever there is a need to create multiple queue consumers, it is recommended to do it via Local Clustering. There is no change in the JMS application, except that the name of a clustered queue is used instead of a physical queue.
J2EE consumers (MDB) are using SwiftMQ's JCA 1.5 Resource Adapter (RA). They cannot reference a clustered queue in the MDB's ejb-jar.xml but must use the linked physical queue directly. This effects only the automatical assignment of linked physical queues to consumers. J2EE consumers have still all features of a clustered queue available, including Local Clustering.