IBMMQ消息通道的配置和維護

IBM WebSphere MQ消息通道的配置和維護介紹（一）

1. 概述

WebSphere MQ做爲IBM軟件家族的消息傳輸中間件產品，以其出色的特性和功能在業界享有盛譽。WebSphere MQ獨特的安全機制、簡便快速的編程風格、卓越不凡的穩定性、可擴展性和跨平臺性，以及強大的消息通信能力，使得它在銀行、電信，仍是在交通運輸、政府機關等各行各業，贏得了很高的市場份額。在中國，WebSphere MQ一樣擁有普遍的用戶基礎和許許多多的成功案例。它不只具備跨平臺、跨網絡的特性，並且以其特有的先進機制保證對消息的"Once and Once only"的傳輸，作到不丟失、不復傳。在WebSphere MQ給客戶帶來的衆多價值中，有一點十分重要，就是它的通信感知和恢復機制，尤爲適用於我國目前的現狀，在我國不少地方存在網絡線路質量差，網絡狀態不穩定的現狀。由於WebSphere MQ在支持同步通信的同時，提供了基於消息隊列存儲-轉發機制的異步通信模式，應用程序只需將消息交給WebSphere MQ，就由WebSphere MQ負責將消息安全、可靠地發送出去，再也不須要應用和人工的干預，當網絡出現故障的狀況下，或對方主機發生故障時，WebSphere MQ可以做到不須要人工干預，自動探測網絡情況的好壞，而且在網絡恢復正常以後可以繼續正常工做，也即斷點續傳。

在WebSphere MQ的系統配置和維護中，通道(Channel)的配置和維護是較複雜也是最重要的部分，本文將對如何配置和維護WebSphere MQ消息通道進行介紹，並附錄有關實現WebSphere MQ隊列管理器雙向通信對象配置腳本。

 

2. 消息通道的配置 2.1 消息通道的類型

消息通道是把消息從一個隊列管理器送到另外一個隊列管理器的通道。不要和MQI通道混淆，MQI通道是在MQ客戶端和MQ服務器隊列管理器之間發送消息的通道。咱們這裏討論的是消息通道。WebSphere MQ中通訊雙方的消息通道類型有6種：

l Sender

l Receiver

l Server

l Requester

l Cluster sender

l Cluster receiver

 

上述消息通道類型配對共有5種：

l Sender-receiver

l Requester-server

l Requester-sender(callback)

l Server-receiver

l Cluster sender-cluster receiver

下面分別對各類組合進行介紹，並給出配置腳本

2.1.1   Sender-receiver

Sender/Receiver通道是最多見的通道配置方式，Sender做爲通道的發送方也是通道鏈接的主動發起方，Receiver做爲通道的接收方也是通道鏈接的被動監聽方。

 

在下面配置腳本中，通道鏈接兩個隊列管理器QM1和QM2。其中，QM1爲Sender方，QM2爲Receiver方。在QM1上配置了遠程隊列（QR2）和傳輸隊列（TO.QM2），其中QR2指向隊列管理器QM2上的本地隊列（QL2），且QR2與TO.QMB2對應，即凡是要放入QR2隊列的消息，在加上傳輸消息頭後直接放入TO.QM2中等待發送。QM1上配置Sender通道（QM1.QM2）須要指定傳輸隊列名以及對方的通訊參數（IP地址和端口），通訊參數必須與QM2上的偵聽程序設置匹配。

Sender通道與傳輸隊列TO.QM2對應，表示凡是在TO.QM2中等待發送的消息最終均可以由該通道送出。雙方通道必須同名。

在鏈接通道的時候，咱們只需在QM1端啓動通道Start channel(QM1.QM2)。

2.1.2   Server-receiver

Server/Receiver與sender/Receiver相似。Server端是消息的發送方，也是鏈接的發起方。在配置的時候，必須指定對方的通訊參數，由CONNAME設定。

 

2.1.3   Server-requester

Server/Requester通道也是一種較常見的通道配置方式，如圖2所示。從消息流向來看，Server做爲消息的發送方，requester做爲消息的接收方。可是從鏈接方式來看，requester倒是鏈接的主動方，server是被動方。這種模式經常使用於動態IP地址的環境中，Server是靜態IP地址的服務器，Requester的機器上網後自動分配到一個IP地址，因此是動態的，由Requester發起鏈接後接收數據。

 

2.1.4   Sender-requester

Sender/Requester的鏈接過程稍微複雜一些，如圖3所示。Requester首先與Sender鏈接，在通知對方鏈接參數後鏈接斷開。Sender進行反向鏈接，消息也是反向傳送的，即由Sender傳給requester。這種反向鏈接的方式，稱爲回調鏈接（callback connection）。這種模式也經常使用於作雙向驗證，即雙方必須都要知道對方的通訊參數才能完成回調鏈接。

 

2.1.5   Cluster sender-cluster receiver

在一個cluster環境中，每個隊列管理器都一個Cluster sender通道，經過這個通道把消息發送到徹底資源隊列管理器，每個隊列管理器也有一個cluster-receiver通道能夠用來接收cluster中的消息。

 

在本文中咱們不重點介紹cluster sender-cluster receiver通道。

 

2.2 消息通道的觸發機制 2.2.1   觸發器原理

觸發（Triggering），是一種自動啓動應用程序的機制。

隊列管理器把某種條件稱爲觸發事件。若是隊列被設置爲觸發類型，而且觸發事件發生了，那麼隊列管理器將發送一個觸發消息到一個稱做啓動隊列的隊列中。觸發消息被放置到啓動隊列的過程意味着產生了觸發事件。

處理隊列管理器中的消息是觸發監控程序(Trigger-Monitor Application)，他的工做是讀取觸發消息並根據觸發消息的信息作出相應的處理。觸發監控程序沒有什麼特殊，它只不過是從啓動隊列讀取消息的應用程序。

當隊列管理器發現由一條消息到達被觸發的隊列以後，它產生的觸發消息將被存放到啓動隊列中，觸發監控程序將從啓動隊列中取出觸發消息，並根據觸發消息中的內容，啓動相應的消息處理程序來處理被觸發隊列中的消息。

觸發所涉及的對象以下所示：

1)        應用隊列(Application Queue)：一個本地隊列並設置爲可觸發。當觸發條件知足時，將會產生觸發消息。

2)        傳輸隊列：若是用觸發方式來啓動通道，則傳輸隊列將對應了觸發的應用隊列。在傳輸隊列的TriggerData屬性中設置爲將被啓動的通道名，這將省略進程的定義。

3)        進程定義(Process Object)：一個應用隊列可能由一個進程定義對象和它關聯。進程定義中包含應用程序的信息。該應用程序負責從應用隊列中取出消息。

4)        觸發事件：它是一種引發隊列管理器產生觸發消息的事件。

5)        觸發消息：當觸發事件發生時，隊列管理器將產生觸發消息。觸發信息來自於應用隊列和於應用隊列關聯的進程定義，它包含了將要被啓動的程序名。

6)        啓動隊列：一個本地隊列。被用來存發觸發消息的隊列。一個隊列管理器可用擁有多個啓動隊列。一個啓動隊列能夠爲多個應用隊列服務。

7)        觸發監控器：是一個持續運行的程序，當一個觸發消息到達啓動隊列時，觸發監控器獲取觸發消息，並利用觸發消息中的信息，啓動應用程序來處理應用隊列中的消息，並把觸發消息頭髮送傳遞給應用程序，消息頭中包含應用隊列名。

 

在全部平臺上，都有一個特殊的觸發監控器叫作通道啓動器（Channel Initator），它的做用就是啓動通道。

IBM WebSphere MQ消息通道的配置和維護介紹（二）

2.2.2   觸發類型

l EVERY：

應用隊列中每接受到一個消息時，都將產生觸發消息。若是應用程序僅僅處理一個消息就結束，可採用這種觸發類型。

l FIRST：

應用隊列中消息從0變爲1時會觸發事件。若是當隊列中的一個消息到達時啓動程序，直處處理完全部消息才結束，則採用這種觸發類型。

l DEPTH：

應用隊列中消息數目和TriggerDepth（引發觸發事件發生時，隊列中的消息數目）屬性值相同時，纔會產生觸發事件。當一系列請求的回覆都收到時，才啓動應用程序，則能夠採用這種方法。

須要注意的時，當DEPTH屬性值爲0的時候，實際上就造成了同步通訊。另外，當採用Depth觸發時，產生觸發消息之後，隊列將被修改成非觸發方式，若是須要再次觸發，須要從新設置成容許觸發。

通常而言，在實際應用中，若是通道設置成觸發方式，觸發類型每每設置成爲FIRST和DEPTH。

2.2.3   觸發器工做流程

1)        本地或遠程應用程序A，往應用隊列(Application Queue)中PUT了一條消息。

2)        若是隊列的觸發類型設置爲first，當隊列原來深度爲0時（隊列爲空），這時PUT一條消息到隊列中將造成觸發事件，同時產生一條觸發消息，觸發消息中將包含進程定義中的信息，由於進程定義中包含啓動程序B所需的信息，因此觸發消息中也包含了啓動程序B所需的信息。

3)        隊列管理器建立觸發消息，並把它PUT入與應用隊列相關的啓動隊列Initiation Queue。

4)        觸發監控器(Trigger Monitor)從啓動隊列(Initiation Queue)中GET觸發消息。

5)        觸發監控器處理觸發消息，發出啓動應用程序B的命令。

6)        應用程序B打開應用隊列(Application Queue)，並處理隊列中的消息。

 

注：若是是通道觸發將能夠不須要建立進程對象（process object），只是在傳輸隊列的trigdata中設置須要啓動的通道名。

 

2.2.4   配置消息通道觸發

配置消息通道觸發啓動，須要使用到的對象有傳輸隊列，通道啓動隊列，發送通道，通道啓動器。咱們本配置案例中傳輸隊列名是QMB，通道啓動隊列採用SYSTEM.CHANNEL.INITQ，發送通道名QMA.QMB，通道啓動器爲runmqchi，該進程在隊列管理器啓動的時候自動啓動。下面咱們經過舉例來演示配置實現消息通道觸發啓動。

l 首先咱們來查看一下傳輸隊列QMB都有哪些屬性，顯示以下清單所示，其中清單中的標註紅色的屬性和通道觸發配置相關。

dis ql(QMB)      1 : dis ql(QMB) AMQ8409: 顯示隊列細節。    QUEUE(QMB)                           TYPE(QLOCAL)    ACCTQ(QMGR)                          ALTDATE(2009-02-06)    ALTTIME(11.41.44)                       BOQNAME( )    BOTHRESH(0)                           CLUSNL( )    CLUSTER( )                             CLWLPRTY(0)    CLWLRANK(0)                             CLWLUSEQ(QMGR)    CRDATE(2008-12-05)                      CRTIME(10.37.53)    CURDEPTH(0)                             DEFBIND(OPEN)    DEFPRTY(0)                              DEFPSIST(NO)    DEFSOPT(SHARED)                         DEFTYPE(PREDEFINED)    DESCR( )                                DISTL(YES)    GET(ENABLED)                            HARDENBO    INITQ( )                                IPPROCS(1)    MAXDEPTH(5000)                          MAXMSGL(4194304)    MONQ(QMGR)                              MSGDLVSQ(PRIORITY)    TRIGGER                                 NPMCLASS(NORMAL)    OPPROCS(1)                              PROCESS( )    PUT(ENABLED)                            QDEPTHHI(80)    QDEPTHLO(20)                            QDPHIEV(DISABLED)    QDPLOEV(DISABLED)                       QDPMAXEV(ENABLED)    QSVCIEV(NONE)                           QSVCINT(999999999)    RETINTVL(999999999)                     SCOPE(QMGR)    SHARE                                   STATQ(QMGR)    TRIGDATA( )                             TRIGDPTH(1)    TRIGMPRI(0)                            TRIGTYPE(FIRST)    USAGE(XMITQ)

 

l 設置傳輸隊列爲觸發模式TRIGGER。

l 設置觸發類型爲every/first/depth其中的一種，例如TRIGTYPE(FIRST)。若是設置爲TRIGTYPE(DEPTH)，則還須要設置觸發深度屬性，例如TRIGDPTH(4)，表示當隊列中的消息數由3個增長到4個的時候才能造成觸發事件，但須要注意的是深度觸發事件只能產生一次事情，下次傳輸隊列的消息數由3個增長到4個時候不會產生觸發事件，因此在消息通道觸發中，咱們推薦採用TRIGTYPE(FIRST)。

l 在通道觸發中，推薦使用SYSTEM.CHANNEL.INITQ隊列做爲初始隊列， 該隊列爲MQ專用的通道啓動隊列, 不須要手工啓動其觸發監視器，設置傳輸隊列INITQ(SYSTEM.CHANNEL.INITQ )屬性。

l 經過TRIGDATA屬性設置須要觸發的通道名，例如TRIGDATA(QMA.QMB )。

l 對於TRIGMPRI屬性的含義是基於消息優先級觸發，也即某類優先級的消息知足的觸發條件才產生觸發事件，咱們在消息通道觸發中不推薦使用。

 

完整MQSC命令參考以下：

ALTER QL(QMB) + TRIGGER + TRIGTYPE(FIRST) + INITQ(SYSTEM.CHANNEL.INITQ) + TRIGDATA(QMA.QMB)

l 通道的觸發監控器咱們採用系統的自帶的runmqchi程序，缺省隊列管理器啓動的時候，runmqchi進程會自動啓動。

 

IBM WebSphere MQ消息通道的配置和維護介紹（三）

2.3 通道主要屬性

消息通道的屬性很是多，下面對一些重要屬性進行介紹。

2.3.1   Channel type屬性

經過的類型(CHLTYPE)有不少種，須要根據通道配對方式，設置您所須要的通道類型。請參看2.1小通道類型。

2.3.2   Connection name屬性

做爲消息通道，只有Sender，Server 和 Requester通道才使用Connection Name(CONNAME)屬性。若是通信協議是TCPIP，該屬性設置能夠指定通訊對方的IP地址和端口號。

2.3.3   Transmission queue name屬性

 

Transmission queue name(XMITQ) 屬性是設置傳輸隊列名，就是通道須要從這個隊列取出消息而後發送到對方。sender 和server通道須要設置XMITQ屬性。

 

2.3.4   Disconnect interval屬性

Disconnect Interval(DISCINT)是發送和服務類型的通道所具備的一個參數，它的做用是：在它設置的時間間隔內，若是傳輸隊列爲空即通道上沒有消息經過時，通道就會被中止。設置完Disconnect Interval參數以後，當發送方重起通道時，通道就會被正常啓動。

Disconnect Interval的值會地影響通道的性能。若是把Disconnect Interval的值設置得很是小，會致使通道的頻繁啓動；反之，若是把Disconnect Interval的值設置得很大，則意味着即便通道上很長時間沒有消息，系統資源也會被長期佔用，從而影響系統的性能。所以，利用改變Disconnect Interval的值，咱們能夠有效地改善通道的性能。

當傳輸隊列中沒有消息要傳送時，發送方通道(SDR)、服務器通道(SVR)將在等待了該參數指定的時間間隔後斷開鏈接，中止通道。該參數以秒爲單位，定義新的通道時，若是沒有特別指定，該參數會繼承系統對象的屬性，設爲6000秒，約兩個小時。亦通道連續兩個小時沒有消息發送後就會中止。DISCINT參數設定爲0，通道永遠不會中止。

 

2.3.5   Heart Beat Interval屬性

與Disconnect Interval(HBINT)相對應的是Heart Beat Interval這一參數(僅針對WebSphere MQ for AIX、HP-UX、OS/二、Sun Solaris、Windows NT/2000 V5.1以上)。它的做用是：在Heart Beat Interval指定的時間間隔內，若是傳輸隊列上沒有一直沒有消息到達，發送方MCA會向接收方MCA發送一個心跳信號，據此給接收方通道以中止的機會，在這種狀況下，它沒必要等待Disconnect Interval超時，也會將通道中止下來。同時，它會釋放用來存貯大消息的內存空間並關閉接收方的隊列。

爲了使HeartBeat Interval和Disconnect Interval這兩個參數更有效地發揮做用，通常狀況下須要讓Heart Beat Interval設置值小於Disconnect Interval設置值。

另外，若是咱們使用的傳輸協議是TCP/IP，咱們也能夠利用設置TCP/IP的socket的SO_KEEPALIVE參數來實現這一功能。設置完SO_KEEPALIVE參數，並設置時間間隔以後，TCP/IP自己就會按期去檢測另外一端鏈接的狀態，若是對方鏈接已斷開，通道也會被中止。在這裏，TCP/IP的時間間隔也應小於WebSphere MQ通道的Disconnect Interval的值。

2.3.6   ShortRetry和LongRetry屬性

在發送類型等類型的通道屬性中，還有四個參數是與通信恢復和通道鏈接有關的，它們是：shortrty,shorttmr,longrty,longtmr,它們的缺省值分別是：10，60，999999999，1200，分別表明短重試時間間隔和次數以及長重試時間間隔和次數，它們的做用和含義在於當通道從running變爲retrying狀態時，按照這四個參數規定的時間間隔和次數進行通道從新鏈接的嘗試，而且先進行短重試，短重試結束後，再進入長重試。

在設計這四個參數時，要注意如下兩點：

1） 要確保短重試+長重試的時間〉故障恢復時間

例如：假設您估計您的系統故障恢復時間爲1個小時，則要設置shorttmr*(time of shortrty)+longtmr*(time of shortrty)>2 hours這樣，才能保證在故障恢復以後，通道仍然可以自動進行從新鏈接的嘗試。

2） 重試間隔將影響自動恢復的效率

例如：若是您把短重試總時間設定爲10分鐘，而長重試時間間隔設爲1小時，而網絡在15分鐘後，便已經恢復，但是此時，因爲通道已經進入長重試階段，它將在1個小時以後，才能經過長重試恢復通道的正常運行。相反，也沒必要把重試間隔設置得過短，應根據須要和用戶的實際狀況進行適中的設置。

 

2.3.7   Batch size屬性

    通道的Batch size(BATCHSZ)值是影響通道性能的一個關鍵參數。在MQ進行消息傳輸時，通道對消息的處理也是在同步點的控制之下並具備交易特性的，在如下條件知足時，它將統一提交一批消息：

當發送的消息個數達到BATCHSZ時；或傳輸隊列爲空，而且在BATCHINT指定的時間間隔內一直沒有消息到達時。

    缺省狀況下，通道的Batchsz是50，這是一個較爲合理和優化的設置。一個小的Batch size值會使每條消息佔用大的資源。好比，假設咱們在局域網的狀況下，Batch size值越大，通道的性能越好。然而，在廣域網環境下，要根據網絡情況的好壞來設置該參數，若網絡情況不好，Batch size值越大，可能會致使通道的性能越差。

2.3.8   NpmSpeed屬性

      WebSphere MQ的消息分爲永久性消息和非永久性消息兩種，對於非永久性消息，通道屬性NPMSPEED能夠設置爲FAST和NORMAL，爲了提升性能，能夠設定該屬性爲FAST。

IBM WebSphere MQ消息通道的配置和維護介紹(四)

2.4 通道通信優化

2.4.1   選擇偵聽程序(Listener)的運行方式

 

MQ的偵聽程序有兩種配置和啓動方式，一種是經過配置/etc/inetd.conf文件選擇使用inetd方式, 也可使用MQ自身提供的runmqlsr程序，所不一樣的是：runmqlsr 是一個線程應用，因此比inetd須要更少的內存消耗。所以，採用runmqlsr方式能夠提升通道相關的性能。

 

2.4.2   選擇通道的運行方式

    與偵聽程序相似，與MQ通道對應的MCA代理程序也能夠有線程和進程兩種運行方式，能夠經過定義通道的MCATYPE屬性來設置通道MCA的運行方式爲thread方式。讓通道以線程方式運行而非進程方式運行，這樣能夠減小通道運行的進程個數和消耗的內存資源。

 

    對於以上兩點，要注意的是：當通道的鏈接個數不少時，如在Unix平臺上超過500個時，建議MCATYPE和listener採用進程的方式。

 

2.4.3   設置偵聽程序的trusted運行方式

    與MQ應用程序相似，MQ的通道偵聽程序也有trusted(fastpath)和non trusted(standard)兩種運行方式，採用trusted運行方式能夠下降CPU和內存消耗。將通道和偵聽程序設置爲trusted方式運行的方法是經過修改qm.ini配置文件中的MQIBindType參數來實現，即建立或修改qm.ini文件中與Channels相關的小節，例如：

 

Channels:

MQIBindType=FASTPATH 或者

MQIBindType=STANDARD

其中，FASTPATH表示trusted運行方式，而STANDARD表示非trusted運行方式。

2.4.4   通道的PipeLineLength屬性

    從MQ版本V5.2開始，MQ提供了一個新的通道參數，即PipeLineLength屬性，經過該屬性，能夠設置MCA採用多個線程的方式來傳輸消息，從而成爲提升通道性能的又一個手段。缺省狀況下，該參數數值爲1，任何大於1的設置MQ自己都會將其設置爲2。

    設置PipeLineLength的方法是修改qm.ini文件的Channels一節，以下：

Channels:

PipeLineLength=2

注意，必須在通道兩端都進行設置，不然會自動取二者之間的最小值。

 

 

2.4.5   設置MaxChannels和MaxActiveChannels屬性

 

    MaxChannels和MaxActiveChannels分別表明隊列管理器容許配置的通道的最大個數和容許同時運行的通道的個數，MaxChannels的缺省值是100，MaxActiveChannels的缺省值與MaxChannels相同。若是您的併發通道鏈接個數超過了100，您須要修改這兩個參數。這對於大併發的Client/Server間通信尤其重要。

2.4.6   使用AdoptNewMCA

在WebSphere MQ的5.2版本以上，新增長了一個控制通道運行的新的參數，既AdoptNewMCA,它能夠經過修改qm.ini文件的Channels一節進行修改,如：

 

 

Channels: AdoptNewMCA=ALL

 

它能夠被設置爲：NO,SVR,SNDR,RCVR,CLUSRCVR,ALL,FASTPATH等值。當MQ接收到啓動通道的請求，可是同時它發現與該通道對應的amqcrsta的進程已經存在，這時，該進程必須首先被中止，而後，通道才能啓動。AdoptNewMCA的做用就是中止這種進程，而且爲新的通道啓動請求啓動一個新的進程。

該屬性能夠將狀態處於running狀態的接收端通道強行終止，從而使發送端的通道啓動或請求操做得以成功。

若是爲某一通道指定了AdoptNewMCA的屬性，可是新的通道因爲"channel is already running"而啓動失敗，則它能夠：

1） 新的通道通知以前的通道中止

2）若是舊的通道在AdoptNewMCATimeout的時間間隔內沒有接受該中止請求，相應的進程（或線程）被kill掉

3）若是舊的通道通過步驟2仍未終止，則當第二個AdoptNewMCATimeout時間間隔到達時，MQ終止該通道，同時產生"channel in use"的錯誤。

 

 

IBM WebSphere MQ消息通道的配置和維護介紹(五)

2.4.7   實現斷網續傳和故障恢復

WebSphere MQ做爲一個消息傳輸產品，自己是架構在TCP/IP之上的，所以與操做系統或網絡底層的TCP/IP特性有着密切的關係，不少狀況下咱們要藉助於修改操做系統的TCP/IP參數，來使它更好地爲WebSphere MQ服務，從而更加完善地發揮WebSphere MQ的強大功能。

當咱們要在WebSphere MQ的兩個隊列管理器之間創建通信時，因爲WebSphere MQ的通道是單向的，咱們必需要創建兩條通道(Chanel)，好比創建兩條類型分別爲發送(sender)類型和接收(receiver)類型的通道來實現兩個WebSphere MQ Server之間的通信，在通道的兩端WebSphere MQ利用MCA(消息通道代理)來管理和監控通道的啓停等運行狀態，並對通道兩端的消息系列號(Message Sequence Number)等進行協同管理，以保證WebSphere MQ對消息的"Once and Once Only"的傳輸。對WebSphere MQ而言，在其系統配置配置文件mqs.ini文件中，在mqs.ini文件中，包含了對隊列管理器的日誌大小、通道屬性以及經過XA標準與數據庫協同工做時的有關參數的設置，除此以外，有一節用於控制有關TCP/IP特性的信息，即：

 

TCP： KeepAlive=Yes或 KeepAlive=No

它的做用在於：當設置KeepAlive=Yes時，表示操做系統的TCP/IP參數設置對WebSphere MQ生效。

因爲WebSphere MQ接收通道的MCA處於通信的被動方，它一直等待從發送方傳來的消息，所以它不知道何時發送方會中止發送消息，也不知道當網絡出現故障時，發送方何時會從工做狀態變爲中止狀態。這時因爲出現網絡故障，網絡鏈接被斷掉，發送方通道狀態會由running狀態變爲retrying狀態，發送方會試圖從新創建網絡鏈接，而這時接收方的通道卻沒有停下來，仍處於一種假"running"的狀態，相應的咱們會獲得一個"Channel is in use"的錯誤信息，致使發送端想重起卻重起不了。出現這一現象的緣由是：當發送方MCA啓動通道並長時間沒有斷開鏈接，這時出現網絡故障，TCP/IP的socket鏈接被破壞，當發送中止通道並從新啓動時，它須要創建一個新的socket鏈接，而接收方仍停留在原來的RECEIVE調用上，它的socket特徵與發送方新的socket特徵不一致，所以新的socket鏈接創建失敗。

咱們能夠利用TCP/IP特性來克服這一點，更好地實現斷網續傳。一般，操做系統的TCP/IP參數的缺省設置是2個小時（常見的操做系統平臺如：Windows 2000/NT以及AIX,HP-UX,Sun Solaris，Linux等，缺省設定均爲2個小時）即發送KeepAlive探測包的時間是2小時，因此須要2個小時的時間它纔會獲知網絡鏈接已經斷開，這對於咱們來講無疑是沒法接受的。在這種狀況下，咱們能夠經過配置TCP/IP KeepAlive參數來提升TCP/IP的響應速度，從而實現網絡故障時WebSphere MQ可以迅速斷開通道鏈接從而從新啓動通道，實現斷網續傳的強大功能。只有這樣，在發送端，MQ的channel才能由running狀態變爲retrying狀態，同時，在接收端，MQ的channel才能由running狀態變爲not found狀態, 這樣，在網絡或主機從新恢復時，通道才能從新創建起鏈接，恢復running狀態。

 

IBM WebSphere MQ消息通道的配置和維護介紹(六)

要實現上述功能，咱們須要做如下兩方面的工做：

1）修改WebSphere MQ系統配置文件mqs.ini，增長以下一節：

 

TCP： KeepAlive=Yes

 

目的是使系統的TCP/IP設置對WebSphere MQ生效。

2）修改操做系統的TCP/IP參數；

在不一樣的系統上，修改TCP/IP參數的方法略有不一樣，現僅以Windows 2000/NT、RISC6000和HP爲例做一簡單說明。

在Windows NT平臺上，咱們利用regedit來修改系統註冊表，修改HKEY_LOCAL_MACHINE\CurrentControlSet\Services\Tcpip\Parameters下的如下三個參數：
KeepAliveInterval,設置其值爲1000
KeepAliveTime,設置其值爲300000(單位爲毫秒，300000表明5分鐘)
TcpMaxDataRetransmissions,設置其值爲5
在RISC6000平臺上， 用no命令修改以下參數:
tcp_keepidle保持TCP/IP鏈接的時間，單位爲0.5秒，缺省值爲14,400，即兩個小時，咱們可將它設爲5分鐘；
tcp_keepinittcp鏈接初始timeout值，單位爲0.5秒，缺省值爲150，咱們可將它設爲50；
tcp_keepintvl鏈接間隔，單位爲0.5秒，缺省值爲150，咱們可將它設爲50；
咱們也能夠修改/etc/rc.net文件，
/usr/sbin/no -o tcp_keepidle=240
/usr/sbin/no -o tcp_keepinit=50
/usr/sbin/no -o tcp_keepintvl=50
注意：直接使用命令行修改，在機器重啓後，會失效；修改rc.net文件，能夠作到永久生效。
在HP平臺上，
對於HP-UNIX V10.20及其在此以前的版本，用/usr/contrib/bin nettune命令來修改有關參數；
對於HP-UNIX V10.30及其以上版本，用/usr/bin/ndd命令來修改有關參數。
在SUN Solaris平臺上，
用ndd -set /dev/tcptcp_keepalive_interval NNN命令來修改有關參數,tcp_keepalive_interval的單位爲毫秒，缺省值爲7200000毫秒，即2個小時。
在SCO OpenServer平臺上，
tcp_keepalive 和 tcp_keepidle 相同，其原先默認值爲 7200 秒，可設爲 600秒。tcp_keepintvl 其原先默認值爲 75 秒，可設爲15秒。均以"秒"爲單位。
運行命令 ifconfig 命令修改：
/etc/inconfig tcp_keepidle
/etc/inconfig tcp_keepintvl
須要注意的一點是通道兩端的KeepAlive參數要保持協調一致，若發送端的KeepAlive值小於接收端的KeepAlive值，則當網絡出現故障時，發送端的通道停下來以後，接收端的通道會仍然停不下來。

IBM WebSphere MQ消息通道的配置和維護介紹(七)

2.5 通道的維護

經過使用MQSC命令DEFINE來建立通道，DELETE刪除通道。用DISPLAY顯示通道屬性，用ALTER修改屬性。注意，通道只有在中止狀態下才能夠被刪除或修改。

例如：

 

 

*建立接收端通道(QMA.QMB) DEFINE CHANNEL(QMA.QMB) CHLTYPE(RCVR) *建立發送方通道(QMA.QMB)，鏈接對方的IP地址爲192.168.1.100，端口爲1415，通道鏈接傳輸隊列TO.QMB DEFINE CHANNEL(QMA.QMB) CHLTYPE(SDR) CONNAME(‘192.168.1.100(1415)’) XMTIQ(TO.QMB)   *刪除通道(QMA.QMB) DELETE CHANNEL(QMA.QMB) *修改通道(QMA.QMB)的批次消息數量爲100 ALTER CHANNEL(QMA.QMB) CHLTYPE(SDR) BATCHSZ(100) *顯示通道(QMA.QMB)的斷開間隔時間 DISPLAY CHANNEL(QMA.QMB) DISCINT *顯示通道(QMA.QMB)的狀態 DISPLAY CHS(QMA.QMB) AL

 

因爲通道是一種特殊的MQ對象，它的某些狀態會隨着通訊環境的改變而變化，好比通道狀態、通道流量、通道消息序號等，咱們稱之爲通道的動態信息。MQSC也提供了一些命令用來動態管理通道。

 

2.5.1   通道start命令

通道的啓動能夠經過MQSC的start channel命令完成，例如格式爲：

START CHANNEL(ChannelName)

 

也能夠在命令行經過runmqchl控制命令完成，二者效果相同，在Windows中還能夠用MQ服務配置成自動啓動方式。

runmqchl在通道鏈接的主動方使用，使用時須要指定隊列管理器名和通道名。

$runmqchl [-m QMgrName] –c ChannelName

選項-m QMgrName表示隊列管理器名，缺省爲缺省隊列管理器。–c ChannelName示通道.

例如：runmqchl –m QM1 –c QM1.QM2

 

在Websphere MQ for Windows產品中，能夠經過WebSphre MQ服務（本地）工具來進行配置。

 

2.5.2   通道stop命令

用MQSC命令STOP CHANNEL能夠中止通道，中止通道也只有在鏈接通道的主動方發起纔有做用。例如格式爲：

STOP CHANNEL(ChannelName)

 

2.5.3   通道reset命令

通道爲傳送的每一條消息分配了一個序列號，它會自動累計增值，每傳送一條消息，雙方的消息序號都會自動加一。這個消息序號在通道中用SEQNUM屬性表示，在雙方鏈接通道的時候會約定一個起始值，之後每傳遞一條消息各自加一。通道的相關屬性SEQWRAP表示序號的最大值，缺省最大值爲999,999,999。序列號越界後自動歸零，從頭開始。通道利用消息序號來標識傳送和確認的消息。

一般狀況下，通道雙方的消息序號計數應該是相同的。然而在某些異常狀況下，會出現雙方序號不一致的狀況，這一般是由於通訊故障後，雙方對前面的某一條（或一批）消息是否發送成功理解不一致。在解決了不肯定（In-doubt）的消息後，能夠用MQSC命令經過重置消息序號將雙方調整到一致。一旦鏈接斷開後，通道重連時雙方MCA會將消息序號同步。若是通訊異常形成序號不一致，能夠在通道發送端用MQSC命令RESET CHANNEL SEQNUM手工將二者同步。

在鏈接通道的主動方重置消息序號會將雙方一塊兒調整，在被動方重置則只設置一端。

RESET CHANNEL(ChannelName) [SEQNUM(number)]