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

There are a set of checks that we can carry out 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. 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. You should undertake 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, 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 only concerned with ME2 and ME3. ME3 hosts a remote message point that represents the message point hosted by 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, through 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 by using a remote message point

This figure is described in the surrounding text.

Figure 2. Publish/subscribe messaging by using a remote message point

This figure is described in the surrounding text.

 

  1. If we 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 might 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, a 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 that 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:

    • If the request state is Requested, the request has been received but no suitable message is available. Check that the request selector matches the available message on the message point.

    • If the request state is "Pending acknowledgement", the request has successfully identified a matching message and attempted to transmit it to ME3. 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.

 

Next steps

If still having problems, contact the IBM customer service representative.    



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