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 running.
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 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 point
Figure 2. Publish/subscribe messaging using a remote message point
- 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).
- 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.
- 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.
- Check the state of the request:
If you are still having problems, contact your IBM customer service
representative.