调查预订未能通过远程消息点接收到发布/预订消息的原因

可执行一组检查以调查通过远程消息点传送消息时,服务集成总线上的预订未接收到发布/预订消息的原因。

开始之前

遵循调查发布/预订消息未到达预订的原因中的步骤,这些步骤包含在继续完成此任务之前应该执行的初步检查和调查任务。

关于此任务

将此任务作为调查发布/预订消息未到达预订的原因的一部分执行。此任务说明如何调查通过远程消息点来将消息传递至非持久预订的发布/预订消息传递方案中的消息流。下列各图说明了两种可能存在的情况。这些图中的虚线表示发布点之间的关系,而实线表示消息流。在图 1 中,总线包含 3 个消息传递引擎:ME1、ME2 和 ME3。发布应用程序连接至 ME1,预订应用程序连接至 ME2 和 ME3。ME1 存放远程发布点,而远程发布点表示由 ME2 和 ME3 存放的发布点。在图 2 中,总线包含 3 个消息传递引擎:ME1、ME2 和 ME3。发布应用程序与 ME1 相连,而预订应用程序与 ME2 和 ME3 相连。ME1 存放远程发布点,而远程发布点表示由 ME2 和 ME3 存放的发布点。预订应用程序 B 与 ME3 相连,并通过 ME2 上的远程预订来从 ME1 中接收发布。下列步骤中将涉及到这些消息传递引擎。
图 1. 使用远程消息点产生点到点消息此图描述如何使用远程消息点产生点到点消息。
图 2. 使用远程消息点发布/预订消息传递此图描述如何使用远程消息点发布/预订消息传递。
下列步骤同时适用于这两种情况。

过程

  1. 通过单击服务集成 -> 总线 -> bus_name -> [拓扑] 消息传递引擎 -> engine_name显示 ME1 的属性。
  2. 在 ME1 的运行时选项卡上,单击 [远程消息点] 远程发布点,然后单击用来表示 ME2 上发布点的远程发布点。单击主题并检查是否列示了使用者的主题。 如果未列示主题,请执行下列检查:
  3. 有可能是在发布消息之后才注册预订的。重新发布消息,并再次进行检查,以了解是否接收到消息。
  4. 在 ME1 上,再次显示用来表示 ME2 上发布点的远程发布点。查看当前出站消息字段的值。
  5. 如果当前出站消息数大于零,那么表示已经生成了消息,但是 ME2 可能尚未接收到这些消息。
    1. 检查这两个消息传递引擎之间是否能够互相通信,请参阅服务集成故障诊断:检查总线中的两个消息传递引擎之间的通信
    2. 在主题空间上查找先前的消息。如果存在先前的消息,并且某些消息或所有消息都是用于 ME2 的,那么应等待一会儿然后刷新该视图。
      • 如果某些消息已经从主题空间中消失了,那么系统当前正在传递消息,但是已经产生了积压。一直等到清除了积压情况之后再检查 ME2 上的发布点,以了解测试消息是否已经到达。
      • 如果没有任何消息从主题空间中消失,那么在“正在落实”状态下捕获到的消息可能会阻止消息的传输。后面的消息必须等待此消息传递完毕之后再传递,否则这些消息的排序将发生混乱。

        如果在“正在落实”状态下捕获到消息,那么该消息将包含在未解析的事务中。资源管理器(例如,数据库)可能已被挂起。使用该资源管理器解决此问题。如果此操作失败,那么记录消息的事务标识, 然后单击服务器 -> 服务器类型 -> WebSphere 应用程序服务器 -> server_name -> 运行时 > [其他属性] 事务服务以显示事务服务的常规属性。使用查看链接来解析其全局标识与消息的事务标识相匹配的事务。

    3. 检查测试消息的状态:
      • 如果测试消息的状态为“暂挂发送”,那么表示消息正在等待进行发送。ME2 可能未接受消息。请完成以下检查:
        • 检查这两个消息传递引擎之间是否能够互相通信,请参阅服务集成故障诊断:检查总线中的两个消息传递引擎之间的通信
        • 检查 ME2 上的发布点未满:显示发布点的运行时属性,并将当前消息深度消息阈值上限进行比较。如果当前消息深度等于消息阈值上限,那么在使用已排队的消息之前,消息传递引擎将不会接受新消息。可以选择重新启动使用者并一直等到清除了积压情况为止,也可以选择删除消息。
        • 检查是否已经传播了配置更改。通过将最新的配置设置部署到 ME2 的应用程序服务器来确保 ME2 知道发布点的存在。
      • 如果测试消息的状态为“暂挂确认”,那么表示已经发送了消息,但是 ME2 可能尚未接收到该消息或者未处理该消息。检查传输队列中没有任何“正在落实”状态的消息排在测试消息之前,然后等待一会儿并再次检查出版物点,以便了解测试消息是否已经到达。如果有消息是在“正在落实”状态下捕获的,那么通过参考以下内容来解决此问题。
      • 如果测试消息(或者另一条消息)处于“正在落实”状态,那么消息包含在未解析的事务中。资源管理器(例如,数据库)可能已被挂起。使用该资源管理器解决此问题。如果此操作失败,那么记录消息的事务标识, 然后单击服务器 -> 服务器类型 -> WebSphere 应用程序服务器 -> server_name -> 运行时 > [其他属性] 事务服务以显示事务服务的常规属性。使用查看链接来解析其全局标识与消息的事务标识相匹配的事务。
  6. 如果已完成的出站消息数大于零,那么表示已经生成了消息并且 ME2 已处理该消息,但是测试消息尚未出现。重新运行生产应用程序,并确保 ME1 上已完成的出站消息数增大(在已完成的出站消息计数增大之前,您可能会发现活动出站消息计数增大)。
    • 如果这些计数都未增大,那么表示在 ME1 中尚未生成消息。检查生产应用程序是否已连接至此消息传递引擎(请参阅确定应用程序与哪个消息传递引擎相连)。
    • 如果这些计数增大了,那么表示消息已到达 ME2,但是该消息已使用,或已发送至异常目标,或者已到期。检查使用者是否存在,并再次执行初步检查。
  7. 如果当前消息数和已完成的消息数都为零,那么通过再次执行相关的初步检查来检查生产应用程序是否正将消息生成到此目标中。
  8. 现在,您就已经检查了 ME1 与 ME2 之间的消息流。如果在图 1 中的预订应用程序 A 或 B 的位置有应用程序,那么表示已经充分调查了这种情况;如果仍然存在问题,那么请您与 IBM 客户服务代表联系。如果在图 2 中的预订应用程序 B 的位置有一个应用程序,换句话说,该应用程序具有远程预订,那么您还需要执行以下步骤来调查 ME2 与 ME3 之间的消息流。要确定您的应用程序是否正在使用远程预订,可显示相关主题空间的发布点,然后查找您的预订并检查发布点的名称。该名称的格式为 topic_space_name@messaging_engine_name。这将告诉您是使用哪个消息传递引擎来存放预订的。如果此消息传递引擎既不是生产应用程序连接至的消息传递引擎,也不是消费应用程序连接至的消息传递引擎,那么说明正在使用远程预订。
  9. 显示 ME2 上的发布点的预订,并在列表中查找您的预订。 如果未列示您的预订,请执行下列检查:
  10. 单击您的预订,然后单击已知远程预订点。在获得的列表中,单击由该图中的 ME3 表示的消息传递引擎的名称。单击消息请求 这将显示 ME2 上的预订已经从 ME3 上的远程预订中接收到的请求。
  11. 如果可能,请启动消费应用程序并确保它主动尝试使用消息(应用程序应该处于“接收并等待”状态或者“已注册异步使用者”状态),然后遵循调查在应用程序正在运行的情况下未通过远程消息点或预订点来使用消息的原因中的指示信息。如果应用程序在相当长的时间内(有足够长的时间来调查问题)不能保持处于“主动使用消息”状态,那么遵循调查在应用程序已停止的情况下未通过远程消息点或预订点来使用消息的原因中的各个步骤。

指示主题类型的图标 任务主题



时间戳记图标 最近一次更新时间: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tju_pubsub_nd_remote
文件名:tju_pubsub_nd_remote.html