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.

About this task

Procedure

Application responses are not received

Procedure

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 integration node 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

Procedure

Scenario: Your application is not receiving publications through the MQ pub/sub broker.
Explanation: If an application has subscribed successfully, 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 integration servers, or multiple integration nodes, is more complex. A response is sent to a subscriber after the message has been processed by the target integration server. Other integration servers (and integration nodes) are updated asynchronously. As a result, there might be a delay before publications made elsewhere are received. If the integration node is busy, there can be a delay before messages are processed fully. In a multi-integration node setup, if communications have been suspended, subscription changes are propagated through the network of integration nodes. Check the channels.

With multiple integration servers or integration nodes, it might be possible to fill intermediate WebSphere MQ queues if the load is high. This situation might be reported in the syslog (if an integration node 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

Procedure

Scenario: When you publish a message, you receive an error response message with reason text MQRCCF_FILTER_ERROR.
Explanation: An integration node 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 integration node 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

Procedure

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

< <

> >

" "

' '

& &
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>
```

Symbol	Escape character
<	<
>	>
"	"
'	'
&	&

The Publication node fails with MQRC 2035

Procedure

Scenario: The Publication node fails with MQRC 2035.
Explanation: IBM® Integration Bus publishes messages with the user ID in the original message, not the integration node service ID.
Solution: You can force IBM Integration Bus to use the integration node 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, IBM Integration Bus continues to use the integration node's user ID.

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

Procedure

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.
IBM Integration Bus 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 IBM Integration Bus for AIX processes) or /usr/lib (for all processes on the system). IBM Integration Bus for AIX configuration does this action for IBM 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 integration node:
```
LIBPATH=/usr/local/lib:/usr/java130/bin mqsistart mybroker
```