MQ通道搭建以及连通性检查

场景:项目开发中使用的mq中间件一直不太熟悉,遇到问题就需要问人,公司的同事也不怎么爱搭理,弄的好受伤!不熟悉的时候只是感觉好难,逼的没办法,好好研究下,发现里面的过程也没想象中的难,

经过一番研究,大致熟悉通道应用之间的联系,在此记录,加油!相信自己,我能行!

1 服务器之间通信的连接

1.1 基本框架

远程队列的定义包含:
1、目标队列的位置
设定目标队列名和队列管理器名
2、传输路径
设定传输队列名

1.2 举例

建立168.33.51.242服务器到168.33.130.188服务器的连接

复制代码
168.33.51.242——定义远程队列,传输队列,通道
echo "DEFINE QREMOTE(IPSP_1) RNAME(IPSP_1) RQMNAME(QMIPSP) XMITQ(SIMUtoIPSP) DEFPRTY(9) DEFPSIST(YES)" | runmqsc QMSIMU echo "DEFINE QLOCAL(SIMUtoIPSP) USAGE(XMITQ) MAXDEPTH(500000) MAXMSGL(10485760) DEFPSIST(YES) TRIGGER TRIGTYPE(FIRST) TRIGDATA(SIMU.IPSP) INITQ(SYSTEM.CHANNEL.INITQ)" | runmqsc QMSIMU echo "DEFINE CHANNEL(SIMU.IPSP) CHLTYPE(SDR) LOCLADDR(168.33.51.242) DISCINT(0) conname('168.33.130.188(1414)') XMITQ(SIMUtoIPSP) TRPTYPE(TCP) REPLACE" | runmqsc QMSIMU echo "START CHANNEL (SIMU.IPSP)" | runmqsc QMSIMU 168.33.130.188——定义通道和本地队列 echo "DEFINE CHANNEL(SIMU.IPSP) CHLTYPE(RCVR) TRPTYPE(TCP)" | runmqsc QMCORP echo "DEFINE QLOCAL (IPSP_1) DEFPSIST(YES) MAXDEPTH(500000) MAXMSGL(1048576) DEFPRTY(9)" | runmqsc QMCORP
复制代码

242服务器上的远程队列,即188服务器的本地队列,242用来发送消息,188服务器用来接收消息。

242服务器上还有一个本地队列(非命令中的传输队列USAGE(XMITQ)) ,即188服务器上的远程队列,242用来接收188服务器传过来的消息,188用来发送消息到242。

以上命令只是建立了242——>188服务器之间的发送连接,还需要建立一条188——>242服务器之间的发送连接,才能实现双方的相互通信

 

mq之间的交互:A——>B, B——>A

A——>B:
A的远程队列IPSP_1就是B的本地队列,A要发消息就发到远程队列中,B要收消息就在本地队列接收。
根据A远程队列IPSP_1中的XMITQ(SIMUtoIPSP)字段可跟踪到A的传输队列SIMUtoIPSP(QLOCAL),传输队列的USAGE(XMITQ)字段是传输队列的标志;
根据传输队列SIMUtoIPSP(QLOCAL)中的TRIGDATA(SIMU.IPSP)字段,可以跟踪到A——>B的传输通道SIMU.IPSP;
根据发送的传输通道SIMU.IPSP中的CHLTYPE(SDR)字段可以判断该通道是用来发送的,conname('168.33.130.188(1414)')可以用来判断通信主机信息,XMITQ(SIMUtoIPSP)可以看到使用该通道的传输队列(并不明确)。
要使发送和接受双方能正常通信必须保证接受方和发送方的通道名称相同!so,在B的服务器上可以看到通道SIMU.IPSP的信息,并且CHLTYPE(RCVR),表示用来接收消息。

B——>A:
B的远程队列就是A的本地队列,B要发消息就发到远程队列中,A要收消息就要在本地队列接收。

后续过程和A——>B一样。

Mq排错过程:
mq消息不能正常的收发就要从发送队列去追踪到通道,一个通道两台服务器检查,一个是发送,一个是接受。
一个通道只是单向的通信,检查完之后还要检查另一端的队列——通道信息,确保正常才能够相互实现通信。

 

 

 

建立168.33.130.188服务器到168.33.51.242服务器之间的连接

复制代码
168.33.130.188——定义远程队列,传输队列,通道
echo "DEFINE QREMOTE(SIMU_1) RNAME(SIMU_1) RQMNAME(QMSIMU) XMITQ(IPSPtoSIMU) DEFPRTY(9) DEFPSIST(YES)" | runmqsc QMIPSP
echo "DEFINE QLOCAL(IPSPtoSIMU) USAGE(XMITQ) MAXDEPTH(500000) MAXMSGL(10485760) DEFPSIST(YES) TRIGGER TRIGTYPE(FIRST) TRIGDATA(IPSP.SIMU) INITQ(SYSTEM.CHANNEL.INITQ)" | runmqsc QMIPSP
echo "DEFINE CHANNEL(IPSP.SIMU) CHLTYPE(SDR) LOCLADDR(168.33.130.188) DISCINT(0) conname('168.33.51.242(1418)') XMITQ(IPSPtoSIMU) TRPTYPE(TCP) REPLACE" | runmqsc QMIPSP
echo "START CHANNEL(IPSP.SIMU) " | runmqsc QMIPSP


168.33.51.242——定义通道和本地队列
echo "DEFINE CHANNEL(IPSP.SIMU) CHLTYPE(RCVR) TRPTYPE(TCP)" | runmqsc QMSIMU echo "DEFINE QLOCAL(SIMU_1) DEFPSIST(YES) MAXDEPTH(500000) MAXMSGL(1048576) DEFPRTY(9)" | runmqsc QMSIMU
复制代码

定义通道时候,其中的传输队列有什么意义,188服务器中出现两个传输队列指向一个通道的情况,怎么解释?

 

2 总结

2.1 消息跟踪

根据各个对象中的属性,可以跟踪消息的传递过程,进而判断mq的设置是否正确:(精华)

 

远程队列——qr
可以查看远端队列管理器 和队列名字
查看本地传输队列XMITQ(SIMUtoIPSP)

 

传输队列——ql
可以查看传输通道TRIGDATA(BANK.IPSP)

 

传输通道——chs
查看本地ip LOCLADDR(168.33.51.242)
查看通道类型 CHLTYPE(SDR) CHLTYPE(RCVR)
远端服务器地址 端口conname
通道另一端的队列管理器 RQMNAME
查看传输队列XMITQ(SIMUtoIPSP)

IBM MQ 队列属性:http://www.ibm.com/support/knowledgecenter/zh/SSFKSJ_8.0.0/com.ibm.mq.explorer.doc/e_properties_queues.htm

2.2 常用命令

 

复制代码
--查看队列状态--
dspmq

--查看通道--
dis chs(*)

--查看队列深度--
display ql(Q_SVC2ADP_4_HTTP) curdepth

 
      

--清除队列消息--
clear ql(Q_SVC2ADP_4_HTTP)

 
      

--查看CCSID--
display qmgr all

 
      

--修改CCSID--
ALTER QMGR [FORCE] CCSID(5488)

 
复制代码

 

发送通道和接收通道的状态不是running?
首先说明,如果长时间没有消息传输,通道的状态会变成不活动状态,这是正常现象。
如果你手动启动通道后,通道状态还不是running,那先查看错误日志(两边的队列管理器都要查看)
/var/mqm/qmgrs/QM1/errors中的错误日志,通常编号01的日志是最新日志。
常见情况是网络不通导致的通道不通!所以首先要保证网络是正常的,我们可以同过telnet对方的IP加监听端口的方法来查看是不是正常。

telnet 192.168.0.2 1415

再有的情况是两边的配置属性有问题,如两边发送和接收通道名不一致,发送通道的连接名配置错误,发送通道中的传输队列配置错误。
我们也可以执行mq中的一个命令来查看通道是不是正常

runmqsc QM1
ping chl(QM1.QM2)

ping操作来查看两边的通道是不是正常,如果正常会返回ping完成。

2.3 查看mq主机的配置信息

从运维那里可以拿到mq的主机和队列管理器的名字。prot ccsid channel这些可以到机器上面去查看:

查看通道:

目前我采用dis chs(*)命令,本地通道一般都不需要到 . 来分割的。不知道理解对不对

 

查看ssid:

runmqsc MQ名
dis QMGR
显示全信息 其中就有CCSID

 查看端口:

确定监听器

display lsstatus(*)

查看监听器上的端口

display listener(QMTWSV2FUNC)

 

3 问题总结

3.1 2059问题

 MQJE001: 完成代码为“2”,原因为“2059” 
 2059 是监听问题,启动MQ后记得启动监听
start   LISTENER(SYSTEM.DEFAULT.LISTENER.TCP)

 

tws项目中出现2059错误,但不是用上述方法解决的。记录如下:

  • 首先查看队列:dspmq

  • 进入队列管理器:runmqsc QMTWSV2FUNC

  • 然后查看监听:display listener(*)

 这里可以用另一个命令进行排除:

列出队列管理器的侦听状态:display lsstatus(*)

 

  • 最后启动监听器即可start listener(QMTWSV2FUNC)

 

ps:对于如何确定通道的监听器目前并不是很清楚!

 

正常情况下。是能够telnet 远程主机和端口的,如果不能够,就按照上面的方法,重启mq的监听

telnet IP 端口

 

3.2 2035问题

mq报“2035”错误
MQRC_NOT_AUTHORIZED

在mq命令行执行如下命令

dis qmgr chlauth

alter QMGR CHLAUTH(DISABLED)

3.3 channel status not found

  • 通道处于关闭状态

1.根据批量队列BATBANK_1追踪下去找不到通道

2.此时先执行

#查看是否已经建立此通道
dis chl(*)

如果已经建立通道。只需要执行

start chl(SIMU.GWFLA)

 可以看到存在未启动的通道,启动即可!

这里我发现在179服务器上启动后,在182服务骑上就可以看到启动的通道了!

3.4 队列管理器异常结束

一台mq服务器,因为重启了电脑,结果显示

解决方案,启动队列管理器:

strmqm QMTWS

 

 3.5 2058问题

启动程序,报2058错误。

复制代码
2017-07-14 10:46:28.096:WARN::Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'r61200201Dispatcher': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private szfs.tws.biz.service.pay.TotalCheckService szfs.tws.biz.dispatcher.R61200201Dispatcher.totalCheck; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'totalCheckService': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private szfs.tws.core.mq.MqSendService szfs.tws.biz.service.pay.TotalCheckService.sender; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'mqSendService': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: szfs.tws.core.mq.core.BaseSendMQService szfs.tws.core.mq.MqSendServiceImpl.singleSend; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sendSingleMQService' defined in file [G:\STSPro\partition-work\tws_ws\build\classes\spring-mq.xml]: Invocation of init method failed; nested exception is szfs.tws.core.mq.TwsMQException: 初始化队列管理器出错(主机:168.11.206.67,管理器:QMTWSV2FUNC,通道:TWSCONN,端口:1414).:
com.ibm.mq.MQException: Completion Code 2, Reason 2058
    at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:422)
    at szfs.tws.core.mq.core.AbstractMQService.init(AbstractMQService.java:59)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
复制代码

 

出现mq问题,首先确定自己配置的队列管理器是否正确,然后到mq服务器上去查看该mq队列是否启动。

这里出现问题,是因为配错了队列管理器。

 

  • 2
    点赞
  • 25
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
提供的源码资源涵盖了安卓应用、小程序、Python应用和Java应用等多个领域,每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写,确保了在对应环境下能够无缝运行。同时,源码中配备了详细的注释和文档,帮助用户快速理解代码结构和实现逻辑。 适用人群: 这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生,还是对其他领域编程感兴趣的学生,这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码,你可以掌握各平台开发的基础知识,提升编程能力和项目实战经验。 使用场景及目标: 在学习阶段,你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码,你将深入了解各平台开发的技术细节和最佳实践,逐步培养起自己的项目开发和问题解决能力。此外,在求职或创业过程中,具备跨平台开发能力的大学生将更具竞争力。 其他说明: 为了确保源码资源的可运行性和易用性,特别注意了以下几点:首先,每份源码都提供了详细的运行环境和依赖说明,确保用户能够轻松搭建起开发环境;其次,源码中的注释和文档都非常完善,方便用户快速上手和理解代码;最后,我会定期更新这些源码资源,以适应各平台技术的最新发展和市场需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值