WebSphere Message Broker, Version 8.0.0.7 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Resolving problems when using publish/subscribe

Use the advice given here to help you to resolve common problems that can occur when you run publish/subscribe applications.

Application responses are not received

  • Scenario: Application responses are not received.
  • Explanation: Depending on the application code, a publisher or subscriber might request confirmation that its message was processed successfully. Responses can make debugging client problems much easier, because a response code is given if a problem occurs.

    Typically, a response is always returned to a subscriber. However, for the publishing side, a message might be published without the knowledge of the originating application (for example, by using the default topic property on the input node, or by using a Compute node to modify this property in a message flow). The results of processing that message are still logged in user trace, which might give clues as to what is happening.

    If a response is not received, it is typically due to one of the following causes:
    • The system is busy. Messages might build up on the input queue, and the client might not be waiting long enough for its response.
    • WebSphere® MQ expiry is being used. There are cases where this option is what is required, but the expiry of the input message is copied to the response. As a result, the message might expire on the input queue, or it might expire on the way back to the client. This situation is not an error, even with a persistent message.
    • The input message or response might have been put to the dead-letter queue, if one is configured. Look on this queue to see if any new messages are there. This situation is typically accompanied by error messages in the log written by the broker that describe the problem. For example, the reply-to queue might have been specified incorrectly in the input message, therefore the reply message has been put to the dead-letter queue.
  • Solution: If your application is not asking for responses (that is, not using messages of type MQMT_REQUEST) consider doing so, particularly when developing applications.

Your application is not receiving publications

  • Scenario: Your application is not receiving publications.
  • Explanation: If an application has subscribed successfully (that is, has received an OK response to a RegSub message), it receives publications that match its subscription.

    Subscribers are sent messages only if they match the topic, the subscription point, and the filter. Because the subscription point is specified in the message flow, not in the publication message, an incorrect message flow setting can cause unexpected failures.

    A user trace of the flow that contains the Publication node shows you whether publications are matching anything.

  • Solution: If a filter is being used, a user trace shows you whether this message is being evaluated as expected.

    The case with multiple execution groups, or multiple brokers, is more complex. A response is sent to a subscriber after the message has been processed by the target execution group. Other execution groups (and brokers) are updated asynchronously. As a result, there might be a delay before publications made elsewhere are received. If the broker is busy, there can be a delay before messages are processed fully. In a multi-broker setup, if communications have been suspended, subscription changes are propagated through the network of brokers. Check the channels.

    With multiple execution groups or brokers, it might be possible to fill intermediate WebSphere MQ queues if the load is high. This situation might be reported in the syslog (if a broker cannot put to a queue because it is full) or in the WebSphere MQ log (if a message coming across a channel cannot be put to the target queue because it is full). If you see messages of this type, display the queue depths on all your queue managers to see if any are almost full.

Publishing a message causes a filter error

  • Scenario: When you publish a message, you receive an error response message with reason text MQRCCF_FILTER_ERROR.
  • Explanation: A broker returns this message to a publication when subscriptions have been registered that specify filter expressions (for Content Based Routing) and an error has been encountered when the broker attempts to filter the published message. This situation can occur, for example, if a message is published that includes unsupported data types, or if the message body is corrupted.

Symbols in subscription filters cause problems

  • Scenario: If you specify certain symbols when you use filters in a subscription, the filter does not work. Sometimes your subscription messages are put to the dead-letter queue, and a number of error messages are written to the local error log indicating MQRFH2 parsing errors.
  • Explanation: The MQRFH2 header employs standard XML encoding, so that its parser interprets some symbols in a special way.
  • Solution: If you want to include these symbols in your filters, use the appropriate escape character to ensure that they are parsed correctly:
    Symbol Escape character
    < &lt;
    > &gt;
    " &quot;
    ' &apos;
    & &amp;

    For example, if you want to use:

    <Filter>Body.e_ALERT_BODY.eqnum<6</Filter>

    specify:

    <Filter>Body.e_ALERT_BODY.eqnum&lt;6</Filter>

The Publication node fails with MQRC 2035

  • Scenario: The Publication node fails with MQRC 2035.
  • Explanation: WebSphere Message Broker publishes messages with the user ID in the original message, not the broker service ID.
  • Solution: You can force WebSphere Message Broker to use the broker service ID in all circumstances by setting the environment variable MQSI_PUBSUB_USE_BROKER_USERID to any value. If there is no MQMD header, or if there is an MQMD header but its UserIdentifier field is blank, WebSphere Message Broker continues to use the broker's user ID.

There are performance problems on AIX when the JIT compiler is not loaded

  • Scenario: There are performance problems on AIX® when the JIT compiler is not loaded.
  • Explanation: The environment variable LIBPATH can affect the loading of the Java™ JIT (just-in-time) compiler on AIX. WebSphere Message Broker for AIX runs correctly without the JIT compiler, but publish/subscribe performance is adversely affected.
  • Solution: Ensure that the JIT compiler runs.

    The JIT compiler loads and runs correctly if LIBPATH is not set, therefore do not set LIBPATH. You can make libraries available by linking them into /var/wmqi/lib (for all WebSphere Message Broker for AIX processes) or /usr/lib (for all processes on the system). AIX platformWebSphere Message Broker for AIX configuration does this action for DB2® libraries.

    If it is necessary to set LIBPATH, update it to include the directory /usr/java130/bin.

    For example, you can use the following command to start the broker:
    LIBPATH=/usr/local/lib:/usr/java130/bin mqsistart mybroker
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2016Copyright IBM Corporation 1999, 2016.

        
        Last updated:
        
        Last updated: 2016-05-23 14:47:39


Task topicTask topic | Version 8.0.0.7 | au16630_