Home

 

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 theamqspsd 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 theNoReg 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 theamqspsd sample to check that the stream is supported by all necessary brokers.

 

Home