Problem determination
Check that you are not using WebSphere MQ facilities that are not supported by WebSphere MQ Publish/Subscribe (see Limitations).
Problems with brokers are reported as AMQ58xx messages, which are described
in WebSphere MQ Messages.
Problems with the command messages sent to brokers by publisher and subscriber
applications are reported in broker response messages (described in Broker responses). Set the MsgType and Report options
in the message descriptor of the command message so that the broker sends
a response message (see The message descriptor).
Even if there are no problems with the brokers and command messages, you
might find that subscribers do not receive the publications they expect. Here
is a list of possible causes:
- One or more of the brokers in the network isn't running.
- The subscription has expired, or failed to be made in the first place.
- Use the amqspsd sample to check that the broker has knowledge
of the subscribing application's subscription.
- If the publishing application is running at a different broker, a channel
might be down.
- Check that all channels between the publishing and subscribing brokers
have been started. If not, the subscriber's publication might be sitting
on a transmission queue.
- If the publishing application is running at a different broker, the subscription
might not have been propagated to that broker yet.
- Even though a subscribing application has received a positive reply to
its Register Subscriber command message, the subscription might not
have propagated to the publishing broker. Check all channels between the subscribing
and publishing brokers. Also check the SYSTEM.BROKER.CONTROL.QUEUE at each
broker, because an intermediate broker might not have processed the propagated
subscription yet.
Note that brokers process publish messages in batches.
This is controlled by the PublishBatchSize parameter (see Broker configuration parameters). The effect of this is that, in general, publish messages
are processed more rapidly than subscriptions. If you are loading your system
with a large number of new subscriptions, there might be a delay before they
are propagated to all brokers in the network.
- The publishing application might not have published successfully.
- Don't always assume that the problem is with the subscribing application.
Make sure that the publishing application received a positive response message
from its broker. If it is publishing using MQMT_DATAGRAM messages and doesn't
specify either the MQRO_NAN or MQRO_PAN report options, the broker won't send
it a reply message, even if the Publish command messages fails. If
such a publishing application doesn't use the NoReg publication
option, it must set up a valid ReplyToQ in the message
descriptor.
- The broker might be putting the subscriber's publications to the dead-letter
queue.
- There might be a problem with the subscriber's queue. For example,
it might be put-inhibited or the publications might be too large for the queue.
In this case the broker, by default, puts these messages to the dead-letter
queue (DLQ). Check the DLQ at the subscriber's broker. The broker also
issues message AMQ5882 if it has had to put a message to the DLQ.
- The stream might not be supported by all necessary brokers.
- If the publication is not being published on the default stream, all brokers
in the network between the publishing and subscribing brokers must support
the stream you are using. Use the amqspsd sample to check that
the stream is supported by all necessary brokers.