Investigating why messages are not being consumed through a remote message point or subscription point, while the application is running

This topic describes how to investigate why messages are not being consumed at a destination on a service integration bus, when the messages are being routed through a remote message point and the consuming application is running.

Before you begin

Follow the steps in either Investigating why point-to-point messages are not being consumed or Investigating why publish/subscribe messages are not arriving at a subscription, whichever best suits the problem. These topics contain preliminary checks and investigative tasks that you should carry out before proceeding with this task.

About this task

You should perform this task as part of either Investigating why point-to-point messages are not being consumed or Investigating why publish/subscribe messages are not arriving at a subscription. This task explains how to investigate the flow of messages in a scenario where the messages are being routed through a remote message point and the consuming application is started. The following diagrams illustrate two possible scenarios. In Figure 1, ME2 is the messaging engine that hosts the message point, and receives messages from the producing application through ME1. ME3 is the messaging engine that the consuming application is attached to, and hosts a remote message point which represents the message point on ME2. In Figure 2, ME2 and ME3 host publication points that are represented by remote publication points on ME1, where the producing application is attached. Subscribing application B is connected to ME3 and receives messages indirectly from ME1, via a subscription on ME2. a remote subscription point on ME 3. These messaging engines are referred to in the following steps.

In the following figure, a bus contains three messaging engines, ME1, ME2 and ME3. The producing application is connected to ME1 and the consuming application is connected to ME3. The messages are routed from ME1 to ME3 through ME2, and are consumed from ME3. This scenario is focused on ME2 and ME3. ME3 hosts a remote message point which represents the message point hosted by ME2.

Figure 1. Point-to-point message consumption using a remote message point This figure is described in the surrounding text.

In the following figure, a bus contains three messaging engines, ME1, ME2 and ME3. The publishing application is connected to ME1 and the subscribing applications are connected to ME2 and ME3. ME1 hosts remote publication points which represent the publication points hosted by ME2 and ME3. Subscribing application B is connected to ME3 and receives publications from ME1 through a remote subscription on ME2.

Figure 2. Publish/subscribe messaging using a remote message point This figure is described in the surrounding text.

Procedure

  1. If you have followed the steps in Investigating why point-to-point messages are not being consumed or Investigating why publish/subscribe messages are not arriving at a subscription before starting this task, you should have displayed a list of message requests. Check that the list contains a request with a selector that matches an available message on the message point on ME2. If there is no such request in the list, the consuming application is not consuming; check the consuming application for errors:
    • Check that the consumer is started.
    • Check that the application is actively trying to consume:
      • If the application uses an asynchronous consumer, check that the asynchronous consumer is registered.
      • If the application is synchronous, check that the consumer is currently in a 'receive with wait' state (this may require a modification to the application to extend the time that the application waits for a message).
  2. Check the state of the active request:
    • If the state is 'Value', a message was retrieved and returned to the consuming application, but the consumption of the message has not yet completed. Check that the consuming application is correctly processing any incoming messages, for example, check that the application is committing the transaction used to consume the message.
    • If the state is 'Rejected', a message was retrieved and returned to the consuming application, which then rejected the message for some reason. Generally, this means that the consuming application rolled back the consume operation or an associated transaction.
    • If the state is 'Acknowledged', an message was returned for the request and consumed by an application. Check that the message was received by the correct application, and was not consumed by a different application.
    • If the state is 'Request', the message request has been sent to ME2, continue to the next check to investigate why a message has not been returned.
  3. Note the Request ID. On ME2, display the message points for the destination, and view the message requests from ME3. Check that there is a request which matches the request ID on ME3. If there is no matching request, ME2 is not aware of the request. Check that the two messaging engines can communicate with each other, see Service integration troubleshooting: Checking the communication between two messaging engines in a bus.
  4. Check the state of the request:

What to do next

If you are still having problems, contact your IBM® customer service representative.



In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 8:25:23 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-zos&topic=tju_pt2pt_not_consumed_remote1
File name: tju_pt2pt_not_consumed_remote1.html