WAS v8.5 > Troubleshoot > Troubleshooting Service integration > Troubleshooting service integration message problems > Investigating why publish/subscribe messages are not arriving at a subscription

Investigating why publish/subscribe messages are not being received by a subscription through a remote message point

There are a set of checks that we can carry out 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.

Follow the steps in Investigating why publish/subscribe messages are not arriving at a subscription, which contains preliminary checks and investigative tasks that you should carry out before proceeding with this task. Complete 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, a bus contains three messaging engines, ME1, ME2 and ME3. The publishing application is connected to ME1 and subscribing applications are connected to ME2 and ME3. ME1 hosts remote publication points that represent the publication points hosted by ME2 and ME3. In Figure 2, a 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 that represent the publication points hosted by ME2 and ME3. Subscribing application B is connected to ME3 and receives publications from ME1 through a remote 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.

  1. Display the properties for ME1 by clicking Service integration -> Buses -> bus_name -> [Topology] Messaging engines -> engine_name.

  2. 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 the consumer topic is listed. If the topic is not listed, complete the following checks:

  3. It is possible the registration of the subscription occurred after the message was published. Republish the message and check again to see if it was received.

  4. On ME1, again display the remote publication point that represents the publication point on ME2. Review the value of the Current outbound messages field.

  5. If the number of current outbound messages is greater than zero, messages have been produced but they might not have been received by ME2.

    1. Check the two messaging engines can communicate with each other, see Service integration troubleshooting: Checking the communication between two messaging engines in a bus.
    2. 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 -> Server Types -> WebSphere application servers -> server_name -> Runtime > [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.

    3. 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. Complete the following checks:

        • Check 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 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 the ME2 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 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 -> Server Types -> WebSphere application servers -> server_name -> Runtime > [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.

  6. 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 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 the producing application is connected to this messaging engine (see Determine 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 complete the preliminary checks again.

  7. If the number of current and completed messages are both zero, check the producing application is producing messages to this destination, by performing the relevant preliminary checks again.
  8. You have now checked the flow of messages between ME1 and ME2. If we have an application which is in the position of Subscribing application A or B in Figure 1, we have investigated the situation fully; if you are still having problems, contact your IBM customer service representative. If we have an application which is in the position of Subscribing application B in Figure 2, in other words an application that has a remote subscription, you must also investigate the flow of messages between ME2 and ME3, using the following steps. To determine if the 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 the producing application is connected to, and the messaging engine the consuming application is connected to, a remote subscription is being used.

  9. Display the subscriptions for the publication point on ME2, and find your subscription in the list. If the subscription is not listed, complete the following checks:

  10. 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.

  11. 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 the 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.


Subtopics


Related information:

Remote subscription [Collection]
Remote subscription [Settings]


+

Search Tips   |   Advanced Search