场景:项目开发中使用的mq中间件一直不太熟悉,遇到问题就须要问人,公司的同事也不怎么爱搭理,弄的好受伤!不熟悉的时候只是感受好难,逼的没办法,好好研究下,发现里面的过程也没想象中的难,java
通过一番研究,大体熟悉通道应用之间的联系,在此记录,加油!相信本身,我能行!spring
远程队列的定义包含:
一、目标队列的位置
设定目标队列名和队列管理器名
二、传输路径
设定传输队列名服务器
创建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服务器之间的发送链接,才能实现双方的相互通讯ui
mq之间的交互:A——>B, B——>Aspa
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服务器中出现两个传输队列指向一个通道的状况,怎么解释?
根据各个对象中的属性,能够跟踪消息的传递过程,进而判断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
--查看队列状态--
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完成。
从运维那里能够拿到mq的主机和队列管理器的名字。prot ccsid channel这些能够到机器上面去查看:
查看通道:
目前我采用dis chs(*)命令,本地通道通常都不须要到 . 来分割的。不知道理解对不对
查看ssid:
runmqsc MQ名
dis QMGR
显示全信息 其中就有CCSID
查看端口:
肯定监听器
display lsstatus(*)
查看监听器上的端口
display listener(QMTWSV2FUNC)
start LISTENER(SYSTEM.DEFAULT.LISTENER.TCP)
tws项目中出现2059错误,但不是用上述方法解决的。记录以下:
这里能够用另外一个命令进行排除:
列出队列管理器的侦听状态:display lsstatus(*)
ps:对于如何肯定通道的监听器目前并非很清楚!
正常状况下。是可以telnet 远程主机和端口的,若是不可以,就按照上面的方法,重启mq的监听
telnet IP 端口
mq报“2035”错误
MQRC_NOT_AUTHORIZED
在mq命令行执行以下命令
dis qmgr chlauth
alter QMGR CHLAUTH(DISABLED)
1.根据批量队列BATBANK_1追踪下去找不到通道
2.此时先执行
#查看是否已经创建此通道
dis chl(*)
若是已经创建通道。只须要执行
start chl(SIMU.GWFLA)
能够看到存在未启动的通道,启动便可!
这里我发如今179服务器上启动后,在182服务骑上就能够看到启动的通道了!
一台mq服务器,由于重启了电脑,结果显示
解决方案,启动队列管理器:
strmqm QMTWS
启动程序,报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队列是否启动。
这里出现问题,是由于配错了队列管理器。
1