There are a set of checks that you 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.
About 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

Figure 2. Publish/subscribe messaging by using
a remote message point
Procedure
- 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 might 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, 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.
- 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.
- 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.
What to do next
If you are still having problems, contact your IBM customer
service representative.