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隊列是否啟動。

這里出現問題,是因為配錯了隊列管理器。

 

1


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM