WebSphere MQ收发消息出现错误特殊案例

WebSphere MQ 收发消息出现错误特殊案例

 

作者：郑佐

日期：2007-11-6

 

摘要

前段时间，单位在实施 BizTalk Server 2006应用集成项目的时候，使用MQSeries适配器时碰到报文数据在消息队列中传输出现数据丢失现象，WebSphere MQ队列管理器通道会断开连接并重试失败。

该问题一开始就已经存在，由于同事在测试查找原因，笔者也没有引起关注，一段时间下来问题没有解决就搁浅了。这次刚好笔者负责的一个BizTalk应用集成项目需要用到MQSeries实现微机到小型机的数据传输，遗留下来的问题还是需要去解决，不过运气不错一个晚上搞定。由于引起该问题的原因有点特别，因此笔者写下解决过程以便可供碰到类似问题的朋友参考。

 

应用环境

多台硬件服务器，配置为HP380G5160、HP380G5130和HP580。

系统：Windows Server 2003 企业版

消息中间件：IBM WebSphere MQ V6.0 for Windows

在两台服务器上部署WebSphere MQ V6.0，使用服务器对服务器方式进行连接。

应用集成平台：BizTalk Server 2006 企业版

6 台BizTalk服务器实现3台BizTalk建立处理组 + 1台ESSO + 2台数据库服务器做主动/主动模式群集。

数据库：SQL Server 2005 企业版

 

错误展现

启动MQ队列管理器中的发送方通道，向远程队列放入报文，接收方通道会自动起来，在接收方通道所在的MQ服务器上对应的本地队列上能够浏览到发过来的报文。不过过一会通道自动处于不活动状态，再次连接失败，重试失败产生系统日志描述如下：

错误1：

事件类型:    错误 事件来源:    WebSphere MQ

事件种类:    无

事件 ID: 9206

日期:       2007-10-29

事件:       19:55:49

用户:       N/A

计算机: NB-TFR1

描述:

数据发送到主机 NB-ZZ (192.168.1.66) 的错误。 在将数据通过 TCP/IP 发送到 NB-ZZ ( 192.168.1.66 ) 时发生错误。其原因可能是通信故障。 

TCP/IP(send) 调用的返回码是10054 X('2746')。 记录这些值并通知系统管理员。

 

错误2：

事件类型:    错误 事件来源:    WebSphere MQ

事件种类:    无

事件 ID: 9208

日期:       2007-10-29

事件:       20:00:05

用户:       N/A

计算机: NB-TFR1

描述:

由主机 192.168.1.66 接收的错误。 

从 192.168.1.66 通过TCP/IP接收数据时发生错误。其原因可能是通信故障。 

TCP/IP (recv) 调用的返回码是10053 (X'2745')。 记录这些值并通知系统管理员。

 

备注：在传输队列上已经设置触发，如果通道处于不活动状态，到消息进入传输队列的时候会自动启动。

 

另外笔者尝试了使用客户机服务器方式来访问MQ队列管理器，出现同样的错误。但是，在单位的Dell服务器上进行同样的测试，该问题不会发生。

 

查找原因

根据错误提示可以确定不是BizTalk Server的问题。

按照调用返回码10054 X('2746')和10053 (X'2745')笔者在Google和Baidu上搜了一下，没有找到问题的解决方案。

在IBM网站上查找解决方案，得到以下一些线索：

CSQX208E TRPTYPE=TCP RC=00000461 or AMQ9208 10054

http://www-1.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&context=SSWHKB&q1=10054&uid=swg21237211&loc=en_US&cs=utf-8&lang=en

 

AMQ9206 10054 (X'2746') econnreset from tcp/ip on a client channel connection to a local server

http://www-1.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&context=SSWHKB&q1=10054&uid=swg21106218&loc=en_US&cs=utf-8&lang=en

 

基本原因描述如下：

Return code 10054 or RC 461 means the connection is reset by peer (ECONNRESET). This usually indicates a problem in the TCP/IP network. There are numerous reasons TCP/IP will sent a reset.

Reasons For TCP/IP Resets

• An application request a connect to a port and ip address for which no server is Listening

• An application closes a socket with data still in the application receive buffer. The connection is reset to allow the remote partner to know that the data was not delivered.

• Any data that arrives for a connection that has been closed can cause a reset.

• An application closes a socket and sets the linger socket option to zero. This will notify TCP/IP that the connection should not linger.

Note** MQ does not code the linger socket option, therefore MQ will not cause a reset.

• An invalid tcp segment arrives for a connection, for example, a bad acknowledge or sequence number can cause a reset.

• The connect request times out. TCP gives up trying to connect to an particular port and ip address and resets the connection.

• A Firewall can reset connections if the packet does not adhere to the firewall rules and policies. For example a source or destination port or ipaddress does not match the firewall rule or policy.

• The retransmit timer expires. TCP gives up trying to retransmit a packet and resets the connection.

 

• A bad hardware device can cause resets

 

初步确定是系统网络设置底层的原因，笔者想起来新到的一批HP服务器运维组的同事都安装了HP Network Configuration Utility工具，可能对网络的一些设置同MQSeries有一些冲突。连接到服务器打开HP Network Configuration Utility。

选择其中一块网络适配卡，打开属性对话框。

第一感觉是Advanced Settings里面的一些设置不当。因此对上面属性中带IP或TCP的属性进行群举测试。最终取消选中TCP Offload Engine的Enabled Value多选框。MQSeries通道自动断开问题不再出现。

同过对话框，可以看到TCP Offload Engine的功能描述如下：

TCP Offload Engine (TOE) reduces the CPU cycles required to process network traffic by shifting processing to the adapter. TOE cannot be enabled on a port that has Jumbo Frames enabled.

 

总结

可见服务器的一些默认设置或增强功能程序的优化设置对一些应用软件来说可能不适用，更有可能造成冲突，而在软件出现问题的情况下往往很难找到问题原因。