Multicast and the MQI

Multicast subscriptions are nondurable; because there are no physical queues involved, there is nowhere to store the offline messages that are created by durable subscriptions.

After an application has subscribed to a multicast topic, it is given back an object handle which it can consume or MQGET from, as if it were a handle to a queue. This means that only managed multicast subscriptions (subscriptions created with MQSO_MANAGED) are supported, that is; it is not possible to make a subscription and 'point' the messages at a queue. This means that messages must be consumed from the object handle returned on the subscription call. On the client, the messages are stored in a message buffer until they are consumed by the client; see MessageBuffer stanza of the client configuration file for more information. If the client does not keep up with the publishing rate, the messages are discarded as required, with the oldest messages discarded first.

It is normally an administration decision whether an application uses Multicast or not, specified by setting the MCAST attribute of a TOPIC object. If a publishing application must ensure that multicast is not used, it can use the MQOO_NO_MULTICAST option. Similarly, a subscribing application can ensure that multicast is not used by subscribing with the MQSO_NO_MULTICAST option.

IBM MQ Multicast supports the use of message selectors. A selector is used by an application to register its interest in only those messages with properties that satisfy the SQL92 query that the selection string represents. For more information about message selectors, see Selectors.