MQ中间件通道状态STATUS(RETRYING)的问题分析与解决方法

这种问题一般发送在发送端,在我们发出启动通道的命令之后,通道进入binding的状态,若网络连接畅通并且通道定义正确,它进入正常running状态,如果出现了如下的一些问题,则通道进入retrying状态。

检查通道状态示例

$ runmqsc QMgrName
dis chs(C)
AMQ8417: Display Channel Status details.
CHANNEL(C)                              XMITQ(QX)
CONNAME(xxx.xxx.xxx.xxx (1416))         CURRENT
CHLTYPE(SDR)                            STATUS(
RETRYING)

原因可能有如下几种

1、网络连接有问题
2、通道定义不正确
3、通道两端的消息序列号(Message Sequence Number)不匹配
4、通道定义中的CONNAME(HostName (PortNumber))使用了主机名但是hosts文件中没有定义
5、接收方不能连通
6、接收端没有启动监听
7、接收端端口占用(比如其它队列管理器占用了该端口)

解决方法

阅读更多

IBM WebSphere MQ消息通道的配置和维护(十一)

2.5.5   通道ping命令

类似于TCP/IP中的ping命令,MQSC命令中也有对通道的PING,格式如下。其中,DATALEN表示PING数据包的大小,可以用16字节到32,768字节。

PING CHANNEL(ChannelName) [DATALEN(16|integer)]

PING命令可以检查对方的队列管理器或端口监听器是否启动,也可以检查对方的通道定义是否正确。但不检查通道的通性状态。换句话说,PING CHANNEL只检查通道能否连通,而不检查目前是否连通。

  1. 附录:MQ对象配置参考

队列管理器QMA和队列管理器QMB是互为双向通讯,它们都分别有本地接收队列,传输队列,死信队列,远程队列,发送通道,接收通道。

队列管理器QMA的对象定义清单:

*定义接收队列QLA

def ql(QLA) maxdepth(10000) defpsist(yes) maxmsgl(1048576)  replace

*定义传输队列TO.QMB

def ql(TO.QMB) usage(xmitq) defpsist(yes) maxdepth(10000) maxmsgl(1048576) +

trigger trigtype(first) trigdata(QMA.QMB) initq(system.channel.initq) replace

 

*定义发送通道QMA.QMB

def chl(QMA.QMB) CHLTYPE(SDR) discint(1800)  +

XMITQ(TO.QMB) CONNAME(‘11.193.9.74(1415)’) trptype(tcp) +

shortrty(10000) shorttmr(30) longtmr(300) longrty(999999999) +

batchsz(50) replace

 

*定义接收通道QMA.QMB

def chl(QMB.QMA) CHLTYPE(RCVR) replace

 

*定义远程队列

def qr(QRB) rname(QLB) rqmname(QMB) xmitq(TO.QMB) defpsist(yes) replace

 

*定义死信队列

def ql(DEADQ) defpsist(yes) maxdepth(20000) replace

alter qmgr deadq(DEADQ)

*

alter ql(system.cics.initiation.queue) defpsist(yes)

 

*修改first触发间隔时间

alter qmgr trigint(5000)

 

阅读更多

IBM WebSphere MQ消息通道的配置和维护(十)

2.5.3   通道reset命令

通道为传送的每一条消息分配了一个序列号,它会自动累计增值,每传送一条消息,双方的消息序号都会自动加一。这个消息序号在通道中用SEQNUM属性表示,在双方连接通道的时候会约定一个起始值,以后每传递一条消息各自加一。通道的相关属性SEQWRAP表示序号的最大值,缺省最大值为999,999,999。序列号越界后自动归零,从头开始。通道利用消息序号来标识传送和确认的消息。

通常情况下,通道双方的消息序号计数应该是相同的。然而在某些异常情况下,会出现双方序号不一致的情况,这通常是因为通信故障后,双方对前面的某一条(或一批)消息是否发送成功理解不一致。在解决了不确定(In-doubt)的消息后,可以用MQSC命令通过重置消息序号将双方调整到一致。一旦连接断开后,通道重连时双方MCA会将消息序号同步。如果通信异常造成序号不一致,可以在通道发送端用MQSC命令RESET CHANNEL SEQNUM手工将两者同步。

在连接通道的主动方重置消息序号会将双方一起调整,在被动方重置则只设置一端。

RESET CHANNEL(ChannelName) [SEQNUM(number)]

 

2.5.4   通道resolve命令

发送方和接收方的通道状态中除了SEQNUM(通道消息序号)参数控制消息传递外,还有LUWID参数。LUWID指的消息批次交易号,对于每一批消息发送方都需要收到接收方的确认信息才认为消息完整无误地送达对方,接着产生下一个LUWID并开始下一批消息传送。如果没有收到确认而与接收方失去联系,这时发送方认为这批消息为不确定(In-doubt)状态。

大多数时候,WebSphere MQ会在通道重连时自动解决不确定状态的问题。当然,我们也可以手工解决。事实上,通道的LUWID分成CURLUWID和LSTLUWID两个参数属性,具体工作过程如下:

l  发送方产生一个批次交易号,设置在CURLUWID并通知接收方

l  接收方将其设置在CURLUWID

l  发送方向接收方一条接一条地传送整批消息

l  接收方在完整地收到消息后,将交易号设置在LSTLUWID,提交整批消息并回送确认信息

l  发送方在接收确认信息后,将交易号设置在LSTLUWID,提交整批消息

l  重复上述步骤。

所以,在发送方出现不确定状态时,只需要比较一个发送方的CURLUWID和接收方的LSTLUWID,就可以知道该批消息在接收端是否已经提交,从而在发送方做出相应的动作即可。具体步骤如下:

1)比较双方的LUWID

  • 对于不确定(In-doubt)状态的发送端:

DISPLAY CHSTATUS(ChannelName) SAVED CURLUWID

  • 对于接收端:

DISPLAY CHSTATUS(ChannelName) SAVED LSTLUWID

2)如果两者相同,说明该批消息在接收端已经完整地收到并提交。在发送端执行:

RESOLVE CHANNEL(ChannelName) ACTION(COMMIT)

3)如果两者不同,说明该批消息在接收端未能完整地收到并提交。在发送端执行:

RESOLVE CHANNEL(ChannelName) ACTION(BACKOUT)