This topic describes how to investigate why publish/subscribe messages
are not being received by a subscription on a service integration bus, when
the messages are being routed through a remote message point.
Before you begin
Why and when to perform this task
Perform this task as part of
Investigating why publish/subscribe messages are not arriving at a subscription.
This task explains how to investigate the flow of messages in a publish/subscribe
messaging scenario where the messages are being routed through a remote message
point to a nondurable subscription. The following diagrams illustrates two
possible situations. The dotted lines in the diagrams indicate relationships
between publication points, whereas the solid lines indicate flow of messages.
In Figure 1, ME1 is the messaging engine that the producing application is
attached to, and ME2 and ME3 are the messaging engines that are hosting the
subscriptions. The publication points on ME2 and ME3 are represented by remote
publication points on ME1. In Figure 2, Subscribing application B, which is
attached to ME3, has a durable subscription which receives messages through
ME2, rather than directly from ME1. In order to do this, ME3 hosts a remote
subscription, which represents the subscription on ME2. The messaging engines
are referred to in the following steps.
Figure 1. Point-to-point message
production using a remote message point
Figure 2. Publish/subscribe messaging using a remote message point
The following steps apply to both the above scenarios.
Steps for this task
- Display the properties for ME1 by clicking -> bus_name -> [Topology] Messaging
engines -> messaging_engine_name.
- On the Runtime tab for ME1, click [Remote
message points]Remote publication points, then click
the remote publication point that represents the publication point on ME2.
Click Topics and check that the consumer's topic is
listed. If the topic is not listed, perform the following checks:
- It is possible that the registration of the subscription occurred
after the message was published. Republish the message and check again to
see if it was received.
- On ME1, again display the remote publication point that represents
the publication point on ME2. Review the value of the Current outbound
messages field.
- If the number of current outbound messages is greater than zero,
messages have been produced but they might not have been received by ME2.
- 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.
- Look for previous messages on the topic space. If there are previous messages,
and some or all of them are for ME2, wait a few moments and then refresh the
view.
- If some of the messages have disappeared from the topic space, the system
is currently delivering messages but is backlogged. Wait until the backlog
has been cleared, then inspect the publication point on ME2 to see if the
test message has arrived.
- If none of the messages have disappeared from the topic space, the transmission
of messages might be blocked by a message that is trapped in the 'Committing'
state. Later messages must wait for this message to be delivered, otherwise
the ordering of messages will be broken.
If a message is trapped in the
'Committing' state, that message is contained in an unresolved transaction.
A resource manager, such as a database, might have hung. Resolve the issue
with the resource manager. If this fails, note the Transaction
ID of the message and click Servers -> Application servers
-> [Content pane] server_name -> [Runtime tab] [Additional
Properties] Transaction Service to display the general properties for
the transaction service. Use the Review links to resolve
the transaction whose Global ID matches the transaction
ID of the message.
- Examine the state of the test message:
- If the status of the test message is 'Pending send', the message is waiting
to be sent. ME2 might not be accepting messages. Perform the following checks:
- 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 that the publication point on ME2 is not full: display the runtime
properties for the publication point and compare the Current message
depth to the High message threshold. If
the current message depth is equal to the high message threshold, the messaging
engine will not accept new messages until the queued messages have been consumed.
Either restart the consumer and wait until the backlog is cleared, or delete
the messages.
- Check that configuration changes have been propagated. Ensure that ME2
is aware of the existence of the publication point by deploying the latest
configuration settings to ME2's application server.
- If the status of the test message is 'Pending acknowledgement', the message
has been sent but ME2 has either not received the message, or not processed
the message. Check that there are no messages in the 'Committing' state ahead
of the test message in the transmit queue, then wait a few moments and examine
the publication point again to see if the test message has arrived.If there
are messages that are trapped in the 'Committing' state, resolve this problem
by referring to the following point.
- If the test message (or another message) is in the 'Committing' state,
the message is contained in an unresolved transaction. A resource manager,
such as a database, might have hung. Resolve the issue with the resource manager.
If this fails, note the Transaction ID of the message
and click Servers -> Application servers -> [Content pane] server_name -> [Runtime
tab] [Additional Properties] Transaction Service to display the general
properties for the transaction service. Use the Review links
to resolve the transaction whose Global ID matches
the transaction ID of the message.
- If the number of completed outbound messages is greater than zero,
messages have been produced and processed by ME2, but the test message has
not appeared. Rerun the producing application and ensure that the number of
completed outbound messages on ME1 increases (you might see the active outbound
message count increase before the completed outbound message count increases).
- If the counts do not increase, the message was not produced at ME1. Check
that the producing application is actually connected to this messaging engine
(see Determining which messaging engine an application is connected to).
- If the counts do increase, the message arrived at ME2, but was either
consumed, sent to the exception destination, or expired. Check for the presence
of consumers, and perform the preliminary checks again.
- If the number of current and completed messages are both zero,
check that the producing application really is producing messages to this
destination, by performing the relevant preliminary checks again.
- You have now checked the flow of messages between ME1 and ME2.
If you have an application which is in the position of Subscribing application
A or B in Figure 1, you have investigated the situation fully; if you are
still having problems, contact your IBM customer service representative. If
you have an application which is in the position of Subscribing application
B in Figure 2, in other words an application which has a remote subscription,
you also need to investigate the flow of messages between ME2 and ME3, using
the following steps. To determine if your application is using a remote subscription,
display the publication points for the relevant topic space, find your subscription
and examine the name of the publication point. The name will be of the form topic_space_name@messaging_engine_name.
This will tell you which messaging engine the subscription is hosted by. If
this messaging engine is different than both the messaging engine that the
producing application is connected to, and the messaging engine that the consuming
application is connected to, a remote subscription is being used.
- Display the subscriptions for the publication point on ME2, and
find your subscription in the list. If the subscription is not
listed, perform the following checks:
- Click your subscription and then click Known remote
subscription points. In the resulting list, click the name of
the messaging engine that is represented by ME3 in the diagram. Click Message
requests. This displays the requests that have
been received by the subscription on ME2, from the remote subscription on
ME3.
- If
possible, start the consuming application and ensure that it is actively trying
to consume a message (the application should be in either a 'receive with
wait' state or an 'asynchronous consumer registered' state), then follow the
instructions in Investigating why messages are not being consumed through a remote message point or subscription point, while the application is running.
If your application cannot remain in an actively consuming state for a significant
length of time (long enough to investigate the problem), follow the steps
in Investigating why messages are not being consumed through a remote message point or subscription point, while the application is stopped.