2016-01-04 109 views
0

我正在嘗試在IBM MQ v8上設置消息通道。IBM MQ消息通道未出現

我在Ubuntu Linux上運行IBM MQ Server 8.x。

我有2個隊列管理器QM1和QM2。

在QM1上,我創建了一個發送者通道,在QM2上,我創建了一個接收者通道。

在QM1:

遠程隊列定義

DEFINE QREMOTE(RMQ1) DESCR('Remote queue for QM2') REPLACE + 
PUT(ENABLED) XMITQ(QM2) RNAME(Q_ON_QM2) RQMNAME(QM2) 

傳輸隊列定義爲一個TCP/IP連接

DEFINE QLOCAL(QM2) DESCR('Transmission queue to QM2') REPLACE + 
USAGE(XMITQ) PUT(ENABLED) GET(ENABLED) TRIGGER TRIGTYPE(FIRST) + 
TRIGDATA(QM1.TO.QM2) INITQ(SYSTEM.CHANNEL.INITQ) 

發件人信道定義

DEFINE CHANNEL(QM1.TO.QM2) CHLTYPE(SDR) TRPTYPE(TCP) + REPLACE DESCR('Sender channel to QM2') XMITQ(QM2) + CONNAME('127.0.0.1(**1491**)') //-- QM2's listener is on 1490 

在第二隊列管理器(QM2)

本地隊列定義

DEFINE QLOCAL(Q_ON_QM2) REPLACE PUT(ENABLED) GET(ENABLED) + 
DESCR('Local queue ') 

接收機信道定義

對於TCP/IP連接:

DEFINE CHANNEL(QM1.TO.QM2) CHLTYPE(RCVR) TRPTYPE(TCP) + 
REPLACE DESCR('Receiver channel from QM1') 

在配置結束時,我的發送方通道保持「重試」狀態,並且接收方通道保持「非活動」狀態。

如何讓這個頻道運行?

+0

你應該看看發送方和接收方QM上的錯誤日誌,它應該告訴你實際的問題。 –

回答

1

乍一看,問題出現在您的端口。 連接的名稱應指定偵聽器實際運行的端口。是1491還是1490?

CONNAME( '127.0.0.1()')// - QM2的監聽器是在1490

驗證偵聽器正在運行的接收QMGR並指定你的CONNAME該端口。

0

發送者通道進入重試狀態可能有很多原因。

1.錯誤的參數。

檢查Valerie建議的連接名稱。確保IP地址和端口號指向接收方隊列管理器。

2.傳輸隊列不可用。

確保傳輸隊列可用。注意:有時傳輸隊列將可用,但它可能被GET禁用,但它可能是在這種情況下,發送器通道也將進入重試狀態。發送者通道以獨佔模式打開傳輸隊列,這意味着如果傳輸隊列由另一個應用程序(如RFHUTIL)打開,則發送者通道將無法訪問傳輸隊列,因此通道將進入重試狀態。所以,確保傳輸隊列不被其他應用程序打開。

3.接收通道不可用。

這可能是接收方隊列管理器關閉時的情況。 另外,請確保接收器頻道的名稱與發送器頻道的名稱相同(在您的情況下,這似乎是正確的)。

4.接收信道和發送器通道出去序列

的接收機信道的發送和信道保持用於消息傳輸的序列號。由於環境問題(如網絡故障),序列號可能在發送者和接收者通道之間不一致。

RESET您的發件人和收件人渠道來解決此問題。

+0

雖然你的前三個答案很棒,但4)不正確。序列號錯誤是一個非常糟糕的事情發生的跡象,從來不是網絡故障的結果。建議僅進行RESET,不進行任何調查就可能導致信息丟失或重複。 –

+0

@MoragHughson根據我的經驗,每當我們看到序列問題時,有人突然停止發送者/接收者頻道,並且消息仍在傳輸。大多數情況下,我們都會做一個RESET頻道,而不用擔心信息丟失。那麼,如果發生序列問題,發送者通道將進入重試狀態,並且消息將堆積在最有可能變爲GET禁用的傳輸隊列中。我沒有看到任何消息丟失的原因,除非在txn隊列中留下未提交的消息,即使在隊列未打開後也不會返回隊列 – nitgeek

+0

@MoragHughson您能否提供一些其他消息丟失情況發生? – nitgeek