WebLogic Integration 中的消息丢失


问题描述
在使用 WLI 的每种集成情况中,WLI 都会向其周围的各种应用程序发送消息或接收来自它们的消息。这些消息还会以异步方式通过 WLI 内部的各种组件。当要求的作业未得到执行(如未调用 JPD、向外部系统发送的消息数与要求的不一致)时,就可能发生了消息丢失。由 WLI 发送给其它系统的消息数可能会与 WLI 接收的消息数不一致,因为有些消息可能在内部使用了,并且有些消息则可能基于应用程序逻辑被拆分成了多个消息。本模式有较多的帮助在跟踪这些消息及使用一些最佳的配置经验避免这些消息。

本模式仅适用于使用任何 Service Pack 的 WLI 8.1。

故障排除
请注意,并非下面所有任务都需要完成。有些问题仅通过执行几项任务就可以解决。

快速链接 为什么发生此问题?
消息进入 WLI 后,会以异步方式通过各种组件(B2B、Message Broker、JPD、Application Integration 和 Controls)。在某些情况下,由于配置不当、异常、网络故障或数据库故障,某些组件将不可用,消息可能因此被困在内部队列中或重新发送尝试次数达到了上限 ( http://edocs.bea.com/wls/docs81/jms/implement.html#1255066 (English)),并被发送到错误队列,后来在某些情况下由于 bug 而丢失。
以下是有关查明和解决此类情况的建议:
  1. 消息丢失检查清单:确保所有 WLI 和应用程序队列都配置了错误队列、重试限制和持久性,以实现可靠的消息传送和避免消息丢失。以下是 WLI 在内部用来进行各组件间通信的队列列表。并非所有队列都可用于所有情况:
B2B:
    1. wli.internal.b2b.rosettanetencoder.queue
    2. wli.b2b.failedmessage.queue
    3. wli.internal.b2b.ebxmlencoder.queue
    4. wli.b2b.mt.event.stream
Message Broker:
    1. wli.internal.egfile.queue
    2. wli.internal.egmq.queue
    3. wli.internal.egmail.queue
    4. wli.internal.egtimer.queue
JPD:
    1. wli.internal.msgtracking.queue
    2. wli.internal.instance.info.buffer
    3. wli.internal.worklist.timer.queue
    4. wli.internal.configfile.request.queue
    5. wli.process.event.stream
    6. cgJWSQueue
    7. ****.queue.AsyncDispatcher
Application Integration:
    1. wli.internal.ai.async.response
    2. wli.internal.ai.async.request
    3. wli.internal.ai.event
    4. wli.internal.ai.event_suspend

下面是一个 JMS Server 的样例配置,为 JMS Server 中的对列指定了 Error 队列、消息重发册书和持续性。

<JMSTemplate Name="TemporaryTmplt"/>
<JMSJDBCStore ConnectionPool="cgJMSPool-nonXA" Name="cgJMSStore" PrefixName="weblogic"/>
<JMSServer Name="cgJMSServer" Store="cgJMSStore" Targets="cgServer" TemporaryTemplate="TemporaryTmplt">
<JMSQueue CreationTime="1109359134254"
   ErrorDestination="ebXMLWeb.queue.AsyncDispatcher_error"
   JNDIName="ebXMLWeb.queue.AsyncDispatcher"
   Name="ebXMLWeb.queue.AsyncDispatcher"
   RedeliveryDelayOverride="1000" RedeliveryLimit="10" StoreEnabled="true"/>
<JMSQueue CreationTime="1109359134314"
   JNDIName="ebXMLWeb.queue.AsyncDispatcher_error"
   Name="ebXMLWeb.queue.AsyncDispatcher_error" RedeliveryLimit="0"/>
</JMSServer>

  1. 重新启动时消息丢失:
如果未正确地对 WLI 进行恢复配置,消息会在服务器重新启动时丢失。
解决方法:http://edocs.bea.com/wli/docs81/bpfaq/recovery.html#1511472
  1. 消息位于死信队列中:如果消息是由未定义订阅规则的通道接收的或订阅过滤器不匹配,就会将消息转到相应的死信通道。不过,如果死信通道上未定义订阅者,就会将消息抛弃。
解决方法:
  1. 确保死信通道有订阅者。
  2. 确保 JPD 订阅了该通道。
  1. AsyncErrorBean 发出警告:如果显示与下面内容类似的 AsyncErrorBean 警告,则表明已达 AsyncDispatcherQueue 的重试限制,消息将被发送到 ErrorQueue。
2003-11-28 19:29:35,889 WARN ExecuteThread: '5' for queue: 'weblogic.kernel.Default' com.bea.wlw.runtime.core.bean.AsyncErrorBean > A message was unable to be delivered from a WLW Message Queue. Attempting to deliver the onAsyncFailure event
解决方法:检查日志文件,找到消息事务回滚的原因。问题可能是由网络问题、数据库问题所致。堆栈跟踪的结尾与下面所示的类似:
at com.bea.wlw.runtime.core.bean.AsyncDispatcherBean.onMessage(AsyncDispatcherBean.java:248) at weblogic.ejb20.internal.MDListener.execute(MDListener.java:370) at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:262) at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2678) at weblogic.jms.client.JMSSession.execute(JMSSession.java:2598) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)


  1. 消息位于 AsyncDispatcher_ErrorQueue 中:对于无状态 JPD 和有状态 JPD,****.queue.AsyncDispatcher_Error 中对消息的处理方式是不同的。以下解决方法也记录于 S-26753 中。
无状态 JPD:对于无状态 JPD,在重试了指定的次数后,消息将被丢入 ErrorQueue。要以变通方式解决该问题,请执行以下步骤:
  1. 再定义一个用户定义错误队列,将其配置为 AsyncDispatcher 队列的 ErrorDestination。
  2. 准备一个轮询此用户定义错误队列的独立 MDB 应用程序,并将消息放回到 AsyncDispatcher 队列。
  3. 缺省情况下,此 MDB 应用程序将处于非活动状态。当清除了导致消息首次在此错误队列中出现的所有错误状况后,将立即部署该应用程序。
有状态 JPD:对于有状态 JPD,必须在异常处理程序中实现故障时冻结,从而将实例冻结,以后可以通过管理控制台解除对实例的冻结。


返回页首

调试 WLI
  1. 启用和解释 WLI 调试:在 WLI 中,若干情况下根异常会被掩盖。因此要了解消息丢失的根源问题或其它问题,最好的方法是启用 WLI 调试。启用调试 B2B 的标志与启用其它组件的不同。
    1. 对于 B2B 组件,请使用 Dbea.eci.debug=X1-99 作为 Java System 属性。在 startWeblogic 中编辑 start 命令。调试信息将被写入服务器日志。
    2. 对于其余组件,请为 startWeblogic 添加 verbose 选项(即 startWeblogic verbose),在 verbose 模式下启动服务器。调试信息将被写入域目录中的 workshop_debug.log 中。
  2. 启用 JMS 调试:底层 JMS 问题也可能会导致消息丢失。请通过执行以下步骤之一,打开 DebugJMSMessagePath="true"DebugJMSXA="true" 标志,对 JMS 进行调试。
    1. 可以使用 weblogic.Admin 命令行实用程序来动态打开和关闭调试选项。
例如,在管理服务器和所有被管服务器上打开 DebugJMSXA:
java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -type ServerDebug -property DebugJMSXA true

    1. 对于要调试的每个服务器,可以编辑 <ServerDebug/> 节中的 config.xml 和 MBean 元素。
例如:
<ServerDebug DebugJMSXA="true" Name="myserver"/>

    1. 可以通过作为系统属性传入的方式在命令行中启用此调试 MBean
例如:
-Dweblogic.debug.DebugJMSXA=true

返回页首

已知的 WebLogic Integration 问题
您可定期查看您的 WebLogic Integration 版本的“发行说明”以获得 Service Pack 中的“已知问题”或“已解决的问题”的详细信息,而且还可浏览与消息丢失有关的问题。  方便起见,下面提供了这些发行说明的链接:
对于需要特别注意之处,请参阅以下已知问题,在相应版本 Service Pack 的发行说明中注明了已有针对它们的解决方法或已有可用的解决方法: 
  1. 为非 process 项目订阅通道的问题:这是一个已知问题,以下 URL 处记录了相应的解决方法:http://edocs.bea.com/wli/docs81/relnotes/relnotesLimit.html#1329781
  2. 向业务 process 发送消息有延迟: 如果遇到向订阅 JMS 通道的业务 process 发送消息有延迟的情况,请参阅以下 URL 处发行说明中记述的已知限制和变通方法:  http://edocs.bea.com/wli/docs81/relnotes/relnotesLimit.html#1226132
  3. 正常关闭服务器时 WLI 8.1 SP2 消息丢失:这是在 Service Pack 3 或更高版本中修正的 bug (CR180185)。解决办法 S-25212 参考了 SP3 中的修正,SP4 的最新下载内容可从以下网址获得:http://commerce.bea.com/showallproducts.jsp
搜索还将返回“发行说明”,以及其它“支持解决方法”和与 CR 相关的信息(在需要更多帮助?中说明)。如果客户签订了技术支持合同,则可以登录 http://support.bea.com/,登录后会看到为 Solutions 和 Bug Central 提供的 Browse portlet,可在其中按产品版本浏览最新提供的 CR。

返回页首

外部资源
  1. 产品文档:http://edocs.bea.com/wli/docs81/index.html
  2. dev2dev 网站:http://dev2dev.bea.com/wlintegration/ 
  3. BEA 新闻组:http://forums.bea.com/bea/category.jspa?categoryID=2007

返回页首

需要更多帮助?
如果您已经理解这个模式,但仍需要其它帮助,您可以:
  1. http://support.bea.com/ 上查询 AskBEA(例如,使用“WLI message loss”),以发现其它已发布的解决办法。技术支持合同客户:确保已经登录,可以访问提供的与 CR 有关的信息。
  2. http://newsgroups.bea.com/ 上,向 BEA 的某个新闻组提出更详细具体的问题。
如果这还不能解决您的问题,并且您拥有有效的技术支持合同,您可以通过登录以下网站来打开支持案例:http://support.bea.com/

反馈

请向我们提供您的意见,说明此支持诊断模式“WLI 消息丢失”一文是否有所帮助,您需要的任何解释,以及对支持诊断模式的新主题的任何要求。


免责声明:

依据 BEA 与您签署的维护和支持协议条款,BEA Systems, Inc. 在本网站上提供技术技巧和修补程序供您使用。虽然您可以将这些信息和代码与您获得 BEA 授权的软件一起使用,但 BEA 并不对所提供的技术技巧和修补程序做任何形式的担保,无论是明确的还是隐含的。

本文档中引用的任何商标是其各自所有者的财产。有关完整的商标信息,请参考您的产品手册。