はじめに

前回はMQIクライアント接続でのMQ操作を行った。

今回は、もう一つの接続形態である、メッセージチャネルを経由したキューの伝搬を確認する。

接続イメージは以下。

↓MQ虎の巻1 より「キューマネージャー接続」の図

↓MQ虎の巻2より「メッセージチャネル」の図

環境構成

前回も利用したコンテナ環境を利用する。

完成イメージは以下。

キューマネージャー、リスナはMQコンテナ起動時にデフォルトで作成されるものを使用する。
各オブジェクトの命名はMQ虎の巻7章:ネーミングルールを参考に以下とする
- リモートキュー：TEST_REMOTE_QUEUE
- トランスミッションキュー：TEST_DEST_QUEUE (宛先ローカルキューと同名)
- 送信側チャネル：QM1.TO.QM2
- 受信側チャネル：QM1.TO.QM2 (送信側と同名)
- 宛先ローカルキュー：TEST_DEST_QUEUE

MQコンテナ起動

今回も公式イメージを利用する。詳細は前回、前々回を参照。

# コンテナ間で名前解決・通信できるようにnetworkを定義
docker network create QM-network

# 永続化用のvolumeを作成
docker volume create qm1data
docker volume create qm2data

# QM1_containerを起動
docker run \
--name QM1_container \
--detach \
--rm \
--network QM-network \
--volume qm1data:/mnt/mqm \
--publish 1414:1414 \
--publish 9443:9443 \
--env LICENSE=accept \
--env MQ_QMGR_NAME=QM1 \
--env MQ_DEV=false \
--env MQ_APP_USER=app \
--env MQ_APP_PASSWORD=passw0rd \
--env MQ_ADMIN_USER=admin \
--env MQ_ADMIN_PASSWORD=passw0rd \
icr.io/ibm-messaging/mq:9.2.4.0-r1

# QM2_containerを起動
# そのままだとホストのポート番号が重複するため、ホスト側にマッピングするポートを1ずつずらしている
docker run \
--name QM2_container \
--detach \
--rm \
--network QM-network \
--volume qm2data:/mnt/mqm \
--publish 1415:1414 \
--publish 9444:9443 \
--env LICENSE=accept \
--env MQ_QMGR_NAME=QM2 \
--env MQ_DEV=false \
--env MQ_APP_USER=app \
--env MQ_APP_PASSWORD=passw0rd \
--env MQ_ADMIN_USER=admin \
--env MQ_ADMIN_PASSWORD=passw0rd \
icr.io/ibm-messaging/mq:9.2.4.0-r1

キューマネージャー・リスナ存在確認

キューマネージャー・リスナは公式MQコンテナ起動時にデフォルトで作成されるものを利用する

# キューマネージャーQM1, QM2それぞれの存在確認。Runningになっている
[root@my-instance ~]# docker exec -it QM1_container dspmq
QMNAME(QM1)                                               STATUS(Running)
[root@my-instance ~]# docker exec -it QM2_container dspmq
QMNAME(QM2)                                               STATUS(Running)


# QM2側のリスナの存在確認。1414ポートでlistenしている
[root@my-instance ~]# docker exec -it QM2_container sh -c "echo \"DISPLAY LSSTATUS(*) ALL\" | runmqsc QM2 "
5724-H72 (C) Copyright IBM Corp. 1994, 2021.
Starting MQSC for queue manager QM2.


     1 : DISPLAY LSSTATUS(*) ALL
AMQ8631I: Display listener status details.
   LISTENER(SYSTEM.LISTENER.TCP.1)         STATUS(RUNNING)
   PID(321)                                STARTDA(2024-12-14)
   STARTTI(19.08.01)                       DESCR( )
   TRPTYPE(TCP)                            CONTROL(QMGR)
   IPADDR(*)                               PORT(1414)
   BACKLOG(100)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

各種キュー・チャネル作成

https://localhost:9443, 9444 でそれぞれのMQに対応したGUIコンソールにアクセスすることができる（前々回を参照）。

以降はGUIで構築していく。

まずはQM1側から進める。https://localhost:9443 を操作する。

リモートキュー

以下の４つを指定。他はデフォルト。

キュー名：TEST_REMOTE_QUEUE
リモート・キュー：TEST_DEST_QUEUE (=宛先ローカルキュー名)
リモート・キュー・マネージャー：QM2
伝送キュー：TEST_DEST_QUEUE (=宛先ローカルキュー名と同名)

トランスミッションキュー

以下２つを指定。「トランスミッションキューであること」以外は普通のローカルキューと違いは無い。
※虎の巻でも「特殊な目的をもつローカルキュー」の一つとして紹介されている

キュー名：TEST_DEST_QUEUE
使用法：伝送

送信側チャネル

以下を指定して作成。接続名の指定が独特である点に注意。docker networkを共有しているため、QM1_containerから、QM2_containerを名前解決でき、ポートもそのまま指定できる。

チャネル名：QM1.TO.QM2
チャネル・タイプ：送信側
接続名：QM2_container(1414)
伝送キュー：TEST_DEST_QUEUE

受信側チャネル

続いてQM2側を構築する。https://localhost:9444 を操作する。

受信側チャネルは単に名前の指定のみ。

宛先ローカルキュー

こちらも単に名前のみ指定して作成。

送信テスト

チャネル接続

QM1側の送信側チャネルを「開始」し、チャネルを接続する

実行中の表示になった。

キュー送信

QM1上のリモートキューを選択し、「メッセージの作成」を押す

適当なメッセージを記載して「送信」

正常にメッセージが作成された。トランスミッションキューに滞留していないことが確認ポイント

QM2側の宛先ローカルキューを見ると、無事にキューが伝搬してきたことがわかる。

補足：

チャネルが断絶した状態でキューを送ろうとすると、キューはトランスミッションキューに滞留する。本番で起きると困る。

チャネルが停止している状態で・・・

リモートキューにエンキューすると

キューはトランスミッションキューに滞留する。こうなると困るので、実運用ではトランスミッションキューの滞留状況を監視しておきたい。

チャネル断絶が解消すると（再度チャネルを開始すると）、

キュー滞留は解消、

QM2へ配送される。これで安心。