Interoperating with WebSphere MQ: Troubleshooting tips

Use this set of specific tips to help you troubleshoot problems when using the WebSphere MQ link or WebSphere MQ server components of the default messaging provider to interoperate with WebSphere MQ. Tips for WebSphere MQ link:

Tips for WebSphere MQ server:

 

The WebSphere MQ link channels do not start

Error messages appear in SystemOut.log or, if we have turned on tracing, in the trace.log file.

  1. Verify that the channel names specified on the WebSphere MQ link sender channel and/or the MQLinkReceiver definitions match those specified on the sender and/or receiver channel definitions in the WebSphere MQ network.

    Channel names are case sensitive.

  2. Verify that the channel sequence numbers are not out of step. If they are, then the channel will remain in a state of retry until the sequence numbers have been reset.

    For a WebSphere MQ link sender channel, we can reset the sequence number to 1 by using the WebSphere MQ link sender channel admin pages. This passes a reset instruction to the WebSphere MQ receiver channel. We can optionally reset the WebSphere MQ receiver channel to a value that matches the WebSphere MQ link sender channel. This does not result in any data being passed to the WebSphere MQ link sender channel, and can be used to resolve sequencing issues.

    For a WebSphere MQ link receiver channel, we have to reset the sequence number in WebSphere MQ through the WebSphere MQ sender channel. If using the WebSphere MQ Explorer on a Windows system, we can right click on the channel and select All Tasks > Reset.

    Look for messages CWSIC3011E, CWSIC3015E.

  3. Verify that both ends of the channel have been defined and configured correctly. It is possible that the channel at the remote end is currently in a stopped state and therefore is currently unavailable. Start the channel at the remote end if possible.

    Look for messages CWSIC3018E, CWSIC3113E, CWSIC3114E, CWSIC3236E.

  4. Verify that the channel sequence number wrap values are the same at both ends of the channel.

    Look for message CWSIC3010E.

  5. Verify that the WebSphere MQ link sender channel is not in an indoubt state. Resolve the channel if required. The channel is resolved by WebSphere MQ. On Windows, if we are using the WebSphere MQ Explorer, we can right click on the channel and select All Tasks>Resolve.

    Look for message CWSIC3065E.

  6. Verify that the listeners have been started, and are listening on the correct ports. By default, service integration listens on port 5558 for inbound connections, and the WebSphere MQ network listens on port 1414.

 

Messages sent across a WebSphere MQ link are not delivered

Error messages appear in the SystemOut.log file or, if we have turned on tracing, in the trace.log file. We can also look for equivalent messages in the WebSphere MQ error logs (or trace files if we have turned on tracing in the WebSphere MQ network).

  1. If sending messages from a service integration bus to a WebSphere MQ network, it is possible that the messages are stored on the service integration bus and waiting to be delivered, but that the WebSphere MQ link sender channel has not been started or is in a retry state.

    Verify that the WebSphere MQ link sender channel is started and in running state.

  2. If sending messages from a WebSphere MQ network to a service integration bus, it is possible that the messages are stored on the transmission queue in the WebSphere MQ network and waiting to be delivered, but that the sender channel in the WebSphere MQ network has not been started or is in a retry state.

    Verify that the sender channel in the WebSphere MQ network is started and in running state.

  3. It is possible that the messages could not be processed or delivered to the target destination and hence they have been placed either on an exception destination on the service integration bus, or on the dead letter queue in the WebSphere MQ network. Verify that the WebSphere MQ Link on the messaging engine is configured properly with the correct foreign bus, queue manager name (service integration bus), sender channel and receiver channel. The sender channel on the WebSphere MQ Link should match the receiver channel on WebSphere MQ. The receiver channel on the WebSphere MQ Link should match the sender channel on WebSphere MQ.

    Look for messages CWSIC3096I, CWSIC3098I, CWSIC3200E, CWSIC3209E.

    Check the exception destinations and the dead letter queue. It is possible that the target destination has not been defined, or is full in which case, determine why messages are not being processed from the target destination.

  4. It is possible that the target destination and the exception destination and/or the dead letter queue are full and that subsequent persistent messages cannot be safely delivered. Under these circumstances the channel is stopped to avoid any loss of messages.

    Look for message CWSIP0291W.

    Determine why messages are not being processed from the target destination.

  5. It is possible that the target destination and the exception destination and/or dead letter queue are full and that subsequent nonpersistent messages are discarded.

    Check the persistence of messages being generated by the applications.

  6. It is possible that the channel has stopped because the remote system cannot accept messages for some reason.

    Look for message CWSIC3080E.

 

An appserver cannot shut down if a WebSphere MQ link sender channel is waiting for its disconnect interval to expire

If a WebSphere MQ link sender channel does not have any messages to deliver, it waits for its specified disconnect interval before timing out. If the application server is shut down while a WebSphere MQ link sender channel is in a wait state, the appserver waits for the WebSphere MQ link sender channel to time out before shutting down. A long disconnect interval might delay the server shutdown. If the appserver shutdown is delayed by a WebSphere MQ link sender channel in a wait state, we have two options:

  • Attempt to put a message onto the transmission item stream for the WebSphere MQ link sender channel. Note that this might not take the channel out of its wait state if the appserver shutdown is already in progress

  • Force the termination of the appserver process.

To reduce possible delays during appserver shutdown, we can specify a smaller value for the disconnect interval. Note that a discount interval of 0 indicates an indefinite wait. For more information about setting the disconnect interval for a WebSphere MQ link sender channel, see Add or modifying a WebSphere MQ link sender channel.

 

When a JMS application sends a message to a WebSphere MQ server, a long list of internal error exception messages is issued, including the CWSJP0019E message

This occurs when a WebSphere MQ server is configured to connect to an unsupported version of WebSphere MQ. In this situation, any attempt by a JMS application to send a message to a service integration bus destination that is a defined to a WebSphere MQ server bus member results in a long list of exception messages. The CWSJP0019E message indicates that it is a version problem: 

com.ibm.ws.sib.remote.mq.exceptions.CorruptRMQSessionException: 
CWSJP0019E: An attempt to connect to WebSphere MQ using the information that is
provided by the WebSphere MQ Server bus member MQServer1-BUS1 resulted in a 
connection to a WebSphere MQ queue manager running on version MQCMDL_LEVEL_600 
on platform MQPL_WINDOWS_NT. This configuration is not supported. Destinations
that are assigned to the WebSphere MQ Server bus member are not accessible.

Verify that we have configured the WebSphere MQ server to interoperate with a supported version of WebSphere MQ. For interoperation with WAS V7.0, the version of WebSphere MQ must be WebSphere MQ for z/OS V6 or later, or WebSphere MQ (distributed platforms) V7 or later.    


Last updated Nov 10, 2010 8:23:07 PM CST