[Version 6.0.2]
WebSphere WebSphere Application Server Express, Version 6.0.x Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

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

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 via a remote message point and the consuming application is stopped.

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.

Why and when to perform this task

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 stopped. 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 via 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.
Figure 1. Point-to-point message consumption using a remote message pointThe 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 via ME2, and are consumed from ME3. In this scenario,
we are interested only in ME2 and ME3. ME3 hosts a remote message point which
represents the message point hosted by ME2
Figure 2. Publish/subscribe messaging using a remote message pointThe 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 via a remote subscription on ME2.

Steps for this task

  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. On the previous panel (runtime properties for the message point), check that the Message requests issued (point-to-point only) or Message requests received (publish/subscribe only) value is greater than zero. If the value is not greater than zero, no requests have been made. Check the consuming application for errors:
    • Check that the application is actually connected to ME2.
    • Check that the application did not produce any errors which could explain why messages are not being consumed.
    • Check that the consumer was started.
    • Check that the application did attempt to consume a message:
      • If the application uses an asynchronous consumer, check that the asynchronous consumer was registered.
      • If the application is synchronous, check that the consumer performed a 'receive' or a 'receive with wait' function (this may require a modification to the application to extend the time that the application waits for a message).
  2. If the number of issued message requests is greater than zero, requests from ME3 to ME2 for messages on the message point have been made. Check that the Completed message requests value is greater than zero. If not, 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.
  3. If the number of completed message requests is greater than zero, requests are being issued by ME3, processed by ME2 and completed back to ME3. To ensure that those requests were made by the actual application being investigated, record the current values of Completed message requests and either Message requests issued or Message requests received. Rerun the consuming application and check that both values have increased. If the values do not increase, the application did not make a request from ME3 to ME2 for this message point (the existing numbers relate to a previous application that was consuming messages). Check the consuming application for errors:
    • Check that the application was started.
    • Check that the name of the destination being consumed from is correct.
  4. If the values do increase, the message request was issued and completed, but no message was returned or processed by the consuming application.
    • Check that the application's selection criteria match the available message or messages on the message point.
    • Check that the application is correctly receiving the message, by checking for application or runtime errors.
If you are still having problems, contact your IBM customer service representative.

Task topic

Terms of Use | Feedback

Last updated: 2 Aug 2005
http://publib.boulder.ibm.com/infocenter/ws60help/index.jsp?topic=/com.ibm.websphere.pmc.express.doc\tasks\tju_pt2pt_not_consumed_remote2.html

© Copyright IBM Corporation 2004, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)