|
|
Oracle Tuxedo /Q の管理者は、次の 3 つのタスクを行います。
コンフィグレーションやキューの属性には、アプリケーションの要件が反映されていなければなりません。そのため、アプリケーション開発者とプログラマがよく協力することが大切です。
キュー機能の使い方を簡単に示すサンプルがソフトウェアに提供されています。詳細については、「サンプル アプリケーション」を参照してください。
Oracle Tuxedo /Q コンポーネントには、3 つのサーバが提供されています。1 つは、TMS_QM という Oracle Tuxedo /Q リソース マネージャ用のトランザクション マネージャ サーバ (TMS) です。このサーバは、キュー機能でグローバル トランザクションを管理します。このサーバは、コンフィグレーション ファイルの GROUPS セクションで定義されていることが必要です。
ほかの 2 つは、TMQUEUE(5) および TMQFORWARD(5) で、ユーザにサービスを提供します。この 2 つのサーバは、コンフィグレーション ファイルの SERVERS セクションで定義されている必要があります。
TMQFORWARD の機能がアプリケーションのニーズを完全には満たさない場合、アプリケーション独自のキュー サーバを作成することもできます。たとえば、エラー キューに移動したメッセージをキューから取り出す特別なサーバが必要な場合があります。
アプリケーションでは、ピア ツー ピア通信を選択することもできます。この通信では、転送サーバを使用せずに、アプリケーションはほかのアプリケーションと、クライアントはほかのクライアントと通信します。
標準要件であるグループ名のタグおよび GRPNO の値 (詳細については UBBCONFIG(5) を参照) のほかに、アプリケーションが使用するキュー スペースごとに 1 つのサーバ グループを定義する必要があります。TMSNAME および OPENINFO パラメータを設定する必要があります。次は、この 2 つのパラメータの例です。
TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:<device_name:<queue_space_name>"
TMS_QM は、Oracle Tuxedo /Q のトランザクション マネージャ サーバの名前です。OPENINFO パラメータの TUXEDO/QM は、$TUXDIR/udataobj/RM にあるリソース マネージャのリテラル名です。<device_name> および <queue_space_name> の値は、状況に応じて決定されます。汎用デバイス リストのパス名、およびキュー スペースに対応付けられた名前をそれぞれ設定します。これらの値は、qmadmin(1) を使用して、Oracle Tuxedo の管理者が指定します。
| 注意: | これらの値は、時系列順に指定されている必要はありません。コンフィグレーション ファイルは、キュー スペースを定義する前でも定義した後でも作成できます。コンフィグレーションが定義され、以前に作成されたキュー スペースとキューが使用できることが重要です。 |
GROUPS セクションのエントリごとに、キュー スペースを 1 つだけ使用できます。CLOSEINFO パラメータは使用されません。
次は、TMQUEUE(5) のリファレンス ページから引用した例です。
*GROUPS
TMQUEUEGRP1 GRPNO=1 TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:/dev/device1:myqueuespace"
TMQUEUEGRP2 GRPNO=2 TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:/dev/device2:myqueuespace"
TMQUEUE(5) リファレンス ページでは、コンフィグレーション ファイルの SERVERS セクションについて詳しく説明しています。ここでは、特に大切な内容について説明します。
TMQUEUE でタイムアウトが認識されるのは、CLOPT パラメータで 2 つのダッシュ (--) の後に -t timeout オプションが指定されている場合です。このタイムアウト値は、サーバでトランザクションが有効ではないことが検出された場合に、サーバ内で開始された操作に適用されます。つまり、クライアントが tpbegin(3c) を呼び出さずに tpenqueue(3c) または tpdequeue(3c) を呼び出した場合、トランザクションは有効になっていません。または、クライアントがトランザクションを開始し、TPNOTRAN フラグを設定してクライアントのトランザクションでキューに要求を登録しない場合に、tpenqueue() または tpdequeue() を呼び出したときも、トランザクションは有効になっていません。timeout のデフォルト値は 30 秒です。tpdequeue 要求の応答で flags に TPQWAIT が設定されている場合、待ち時間が -t timeout に指定された時間 (秒単位) を超えると、TPETIME エラーが返されます。
| 注意 : | ctl は、TPQCTL 型の構造体で、tpenqueue(3c) および tpdequeue(3c) で使用されて、呼び出し側プロセスとシステム間でパラメータの受け渡しが行われます。TPQWAIT は、tpdequeue のフラグ設定の 1 つで、プロセスが応答メッセージを待機することを示します。この構造体の詳細については、「TPQCTL 構造体」および「TPQUEDEF-REC 構造体」を参照してください。COBOL でこれに相当するものは、TPQUEDEF-REC レコードです。 |
キュー スペース名、キュー名、およびサービス名は、混同しやすいので注意してください。まず、メッセージ キュー サーバ TMQUEUE の指定では注意が必要です。このサーバをコンフィグレーション ファイルで指定する場合は、CLOPT パラメータの -s フラグを使用して、サーバのあるインスタンスからサービスを受け取るキュー スペースの名前を指定できます。これは、関数 TMQUEUE で宣言されたサービスと同じです。キュー スペースを 1 つだけ使用するアプリケーションでは、CLOPT -s オプションを指定する必要はありません。デフォルトの -s TMQUEUE:TMQUEUE が使用されます。アプリケーションに複数のキュー スペースが必要な場合、キュー サーバの SERVERS セクションの -s オプションの引数として、キュー スペースの名前を指定します。
この指定を行う別の方法としては、buildserver(1) を使用してメッセージ キュー サーバを再度ビルドし、同じように -s オプションを使用してキュー スペースの名前を指定することができます。この方法では、実行可能サーバにサービス名が固定、つまり「ハード コーディング」されます。
# 次の 2 つの指定は同じです。
*SERVERS
TMQUEUE SRVGRP="TMQUEUEGRP1" SRVID=1000 RESTART=Y GRACE=0 \
CLOPT="-s myqueuespace:TMQUEUE"
および
buildserver -o TMQUEUE -s myqueuespace:TMQUEUE -r TUXEDO/QM \
-f ${TUXDIR}/lib/TMQUEUE.o
次のコードが続きます。
..
..
..
TMQUEUE SRVGRP="TMQUEUEGRP1" SRVID=1000 RESTART=Y GRACE=0 \
CLOPT="-A"
前の節で、メッセージ キュー サーバ内のサービス (キュー スペース名) の指定について説明しました。この機能を使用すると、キューのデータ依存型ルーティングを行うことができます。データ依存型ルーティングでは、メッセージがキューに登録されて、メッセージ バッファのフィールド値に応じて特定のグループ内のサービスによって処理されます。その場合、同じキュー スペース名を 2 つの異なるグループに指定します。そして、ルーティングをコンフィグレーション ファイルで設定して、キューにあるメッセージの処理を行うグループを指定します。次は、TMQUEUE(5) のリファレンス ページから引用した例です。キュー スペース名は変えてあります。
*GROUPS
TMQUEUEGRP1 GRPNO=1 TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:/dev/device1:myqueuespace"
TMQUEUEGRP2 GRPNO=2 TMSNAME=TMS_QM
OPENINFO="TUXEDO/QM:/dev/device2:myqueuespace"
*SERVERS
TMQUEUE SRVGRP="TMQUEUEGRP1" SRVID=1000 RESTART=Y GRACE=0 \
CLOPT="-s ACCOUNTING:TMQUEUE"
TMQUEUE SRVGRP="TMQUEUEGRP2" SRVID=1000 RESTART=Y GRACE=0 \
CLOPT="-s ACCOUNTING:TMQUEUE"
*SERVICES
ACCOUNTING ROUTING="MYROUTING"
*ROUTING
MYROUTING FIELD=ACCOUNT BUFTYPE="FML" \
RANGES="MIN-60000:TMQUEUEGRP1,60001-MAX:TMQUEUEGRP2"
TMQUEUE では、ATMI のすべての標準バッファ タイプがサポートされています。アプリケーションでほかのバッファ タイプを追加する必要がある場合は、$TUXDIR/tuxedo/tuxlib/types/tmsypesw.c をコピーし、独自のバッファ タイプのエントリを追加し、最終行の NULL が残っていることを確認し、変更したファイルを buildserver(1) コマンドへの入力として使用します。buildserver コマンドの使用例については、TMQUEUE(5) のリファレンス ページを参照してください。
追加したサーバ名は、CLOPT パラメータ (前述を参照) に指定せずに、buildserver コマンドの -s オプションを使用して TMQUEUE に対応付けることができます。
バッファのサブタイプは tpalloc(3c) サブタイプ パラメータを使用して割り当てることができ、tptypes(3c) 関数を使用して後でそれを取得できます。この機能により、ユーザ定義の ATMI バッファ タイプを新しく作成せずに、データに型を割り当てることができます。これは、文字配列 (CARRAY) または文字列 (STRING) を含むバッファで特に有用です。
TMQFORWARD(5) は、Oracle Tuxedo /Q で提供される 3 番目のサーバです。このサーバは、指定されたキューからメッセージを取り出し、tpcall(3c) を介してそのメッセージを Oracle Tuxedo サーバに渡し、対応する応答メッセージを処理します。コンフィグレーション ファイルでサーバを定義する方法については、TMQFORWARD(5) のリファレンス ページを参照してください。ここでは、特に大切な内容について説明します。
TMQFORWARD は 1 つのサーバであり、アプリケーションで使用される各インスタンスは、コンフィグレーション ファイルの SERVERS セクションで定義されていなければなりません。ただし、TMQFORWARD には、通常のサーバとは異なる次のような特徴があります。次に例を示します。
TMQFORWARD のインスタンスは、キューに対応するサーバ グループを使用して、そのキュー スペースに結び付けられます。特に、そのグループの OPENINFO 文の第 3 フィールドを使用して、キュー スペースと結び付けられます。以下に、これ以外の主なパラメータ、特に 2 つのダッシュに続く CLOPT パラメータについて説明します。
-qqueuename,queuename は必須パラメータです。. . このパラメータは、サーバのこのインスタンスが確認する 1 つ以上のキューを指定します。queuename は、最大 15 文字までの NULL で終了する文字列です。これは TMQFORWARD によって一度キューから取り出された待機メッセージを処理するアプリケーション サービス名と同じです。また、この名前は、メッセージ キュー サーバ TMQUEUE を呼び出す準備をするときに、プログラマが tpenqueue(3c) または tpdequeue(3c) の 2 番目の引数として指定する名前でもあります。
TMQFORWARD は、TMQFORWARD が開始して終了するトランザクション内で機能します。-t trantime オプションは、トランザクションがタイムアウトになるまでの時間 (秒単位) を指定します。TMQFORWARD がキュー上にメッセージがあることを確認すると、トランザクションが開始されます。応答が応答キューまたは異常終了キューのいずれかに登録されると、そのトランザクションがコミットされます。そのため、トランザクションには、メッセージを処理するサービスの呼び出しと応答の受信が含まれています。デフォルト値は 60 秒です。
TMQFORWARD は一度呼び出されると、割り当てられているキューを定期的に確認します。キューが空であった場合は、-i idletime 秒間停止してから再度確認を行います。値が指定されていない場合、デフォルト値の 30 秒が使用されます。この値を 0 に設定すると、キューが継続的に確認されます。これは、キューが空の場合が多いときは、CPU リソースを浪費することになります。
-e オプションが指定されていると、キューが空の場合にサーバが正常に停止し、ユーザ ログ メッセージが生成されます。この機能は、キューに指定するしきい値コマンドに対して使用します。-e オプションとしきい値コマンドの詳細については、「キュー スペースとキューの作成」を参照してください。
サービス要求が TMQFORWARD から呼び出された後で異常終了した場合、トランザクションはロールバックされ、後で再試行できるようにメッセージは (キューに指定された再試行の制限回数まで) キューに戻されます。-d オプションを使用すると、次の処理も行われます。つまり、異常終了したサービスで NULL 以外の応答が返された場合、異常終了キューがメッセージに対応付けられ、キューが存在するときは、応答 (および、それに対応付けられた tpurcode) が異常終了キューに登録されて元の要求メッセージは削除されます。また、-d オプションを使用すると、キューに設定されてた再試行回数の制限値に達すると同時に元の要求メッセージが削除され、元の要求メッセージはエラー キューに登録されます。
このオプションで重要なことは、ただむやみに再試行するのではなく、発信元のライアントが異常終了メッセージを調べ、再試行が必要であるかどうかを判断するようにコーディングできることです。これにより、本質的な問題、たとえば、アカウントが存在していないめに、レコードが「見つからない」場合などが原因で失敗した場合に、それを処理する方法が提供されます。
カスタマイズしたアプリケーション バッファ タイプをタイプ スイッチに追加し、buildserver(1) コマンドを使用して TMQFORWARD に組み込むことができます。ただし、TMQFORWARD をカスタマイズした場合は、-s オプションでサービス名を指定することはできません。
コンフィグレーション パラメータについて、UBBCONFIG パラメータの観点から説明してきました。ただし、GROUPS セクションおよび SERVERS セクション内の指定は、tmconfig(1) を使用して、実行中のアプリケーションの TUXCONFIG ファイルに追加することもできます。「tmconfig、wtmconfig(1)」を参照してください。グループおよびサーバは、一度定義したら再起動する必要があります。
ここでは、qmadmin(1) の 3 つのコマンドについて説明します。これらのコマンドは、Oracle Tuxedo /Q コンポーネントのリソースを設定するために使用します。APPQ_MIB 管理情報ベース (MIB) を使用すると、Oracle Tuxedo /Q をプログラムで管理できるようになります。MIB の詳細については、APPQ_MIB(5) のリファレンス ページを参照してください。
qmadmin のほとんどの主なコマンドでは、位置パラメータが使用されています。コマンドの呼び出し時に、コマンドラインに位置パラメータ (オプションの前にダッシュ (-) が付かないパラメータ) が指定されていない場合、必要な情報を入力するように qmadmin で要求されます。
汎用デバイス リスト (UDL) は、Oracle Tuxedo で制御される VTOC ファイルです。このファイルは、Oracle Tuxedo を実行するマシンに物理的な記憶空間をマッピングします。UDL のエントリは、キューとキュー スペースのメッセージが格納されるディスク領域を指定します。Oracle Tuxedo はその領域への入出力を管理します。Oracle Tuxedo の新規インストールの一部としてキュー機能がインストールされる場合、コンフィグレーション ファイルの初回のロード時に、tmloadcf(1) によって UDL が生成されます。
キュー スペースを作成する前に、UDL にそのキュー スペースのエントリを作成する必要があります。次は、コマンドの例です。
# まず、/Q 管理インタフェース qmadmin を呼び出します。
# QMCONFIG 変数は、UDL が置かれる既存のデバイスを
# 指定します。
QMCONFIG=/dev/rawfs qmadmin
# 次に、デバイス リストのエントリを作成します。
crdl /dev/rawfs 50 500
# 上記のコマンドは、ブロック 50 で開始される物理ページを 500 個確保します。
# UDL に以前にリストされたエントリがない場合、オフセット (ブロック番号) として 0 を使用します。
既存の Oracle Tuxedo UDL にエントリを追加する場合は、QMCONFIG 変数の値には TUXCONFIG で指定されたパス名と同じ値を指定する必要があります。qmadmin を一度呼び出したら、新しいエントリを作成する前に、lidl コマンドを実行してどの領域を使用できるのかを確認します。
キュー スペースでは、IPC リソースが使用されます。そのため、キュー スペースを定義する場合は、共用メモリ セグメントとセマフォを割り当てることになります。前述のように、このコマンドを使用する簡単な方法はプロンプトを表示することです。また、APPQ_MIB(5) の T_APPQSPACE クラスを使用して、キュー スペースを作成することもできます。プロンプトは以下の順で表示されます。
> qspacecreate
Queue space name: myqueuespace
IPC Key for queue space: 230458
Size of queue space in disk pages: 200
Number of queues in queue space: 3
Number of concurrent transactions in queue space: 3
Number of concurrent processes in queue space: 3
Number of messages in queue space: 12
Error queue name: errq
Initialize extents (y, n [default=n]):
Blocking factor [default=16]: 16
このプログラムでは、最後の 3 行を除くすべてのプロンプトに値を入力する必要があります。この例からわかるように、最後の 2 つのプロンプトではデフォルト値が使用されています。error queue name の名前はほとんどの場合に必要ですが、必須ではありません。ここで名前を指定した場合は、qcreate コマンドを使用してエラー キューを作成する必要があります。error queue name の名前が指定されていないと、通常は (たとえば、再試行回数の上限値に達した場合などに) エラー キューに送られるメッセージは、永続的に失われることに注意してください。
共用メモリの予約領域は、キュー スペース内のすべてのキューの永続的ではないメッセージを格納するために使用されます。プログラムでは、この予約領域のサイズを指定するように要求されません。永続的ではない (メモリ ベースの) メッセージが必要な場合は、qspacecreate コマンドラインに -n オプションを入力して、メモリ領域のサイズを指定する必要があります。
IPC キーには、ほかの IPC リソースの要件と競合しない値を指定します。この値は 32,768 より大きく 262,143 未満にします。
キュー スペースのサイズ、キューの数、および一度に登録できるメッセージの数は、アプリケーションのニーズによって決定されます。UDL エントリで指定されたページ数より大きいサイズを指定することはできません。また、これらのパラメータに関連して、キュー スペース内の個々の queue capacity パラメータを検討する必要があります。これらのパラメータを使用すると、(a) キューに登録できるメッセージの上限値を設定し、(b) キューに登録されたメッセージの数がしきい値に達したときに実行するコマンドの名前を指定できます。キュー スペースに同時に登録できるメッセージの数を小さくすると、キューのしきい値に達しなくなります。
並列トランザクションの数を計算するには、以下の各項目を 1 つのトランザクションとしてカウントします。
クライアント プログラムが tpenqueue を呼び出す前にトランザクションを開始する場合、キュー スペースに同時にアクセスするクライアント数だけカウント数を増やします。最悪のケースは、すべてのクライアントがキュー スペースに同時にアクセスすることです。
同時実行プロセスの数としては、このキュー スペースを使用するグループの TMQUEUE サーバ、TMQFORWARD サーバ、または TMS_QM サーバごとに 1、余裕として 1 をカウントします。
qspacecreate コマンドの使用時に、キュー スペースを初期化するように設定できます。また、キュー スペースを初めて開くときに、qopen コマンドで初期化するように設定することもできます。
使用するキューは、qmadmin の qcreate コマンドで作成する必要があります。まず、qopen コマンドでキュー スペースをオープンします。キュー スペース名が指定されていない場合は、qopen で名前を入力するように求められます。APPQ_MIB(5) の T_APPQ クラスを使用して、キューを作成することもできます。
> qcreate
キュー名: service1
キューの順序 (優先順位、時刻、有効期限、fifo、lifo): fifo
順序無視のキュー登録 (top, msgid, [デフォルト値=none]): none
再試行回数 [デフォルト値=0]: 2
再試行遅延時間 [デフォルト値=0]: 30
キュー容量警告の上限しきい値 (b はバイト数、B はブロック数、
% は使用中のパーセント値、m はメッセージ。[デフォルト値=100%%]): 80%
キュー容量警告の下限しきい値 [デフォルト値=0%]): 0%
キュー容量警告コマンド名:
キュー容量警告コマンドのデフォルト値はありません。
キュー 'service1' が作成されました。
これらすべてのプロンプト (queue name のプロンプト以外) では、入力を省略できます。queue name が指定されていない場合、プログラムで警告メッセージが表示され、再度プロンプトが表示されます。これ以外のパラメータについてはプログラムでデフォルト値が用意されており、デフォルト値の使用を通知するメッセージが表示されます。
デフォルトの配信オプションやメモリのしきい値のオプションを入力するようには求められません。デフォルトの配信オプションを使用すると、配信モードが指定されていないメッセージを永続 (ディスク ベースの) ストレージに配信するか、または非永続 (メモリ ベースの) ストレージに配信するかを指定できます。メモリのしきい値オプションでは、非永続メモリのしきい値に達したときに、コマンドを実行するための値を指定できます。これらのオプションを使用するには、qcreate コマンドラインで -d と -n をそれぞれ指定する必要があります。
メッセージは、このパラメータで指定された順序でキューに登録され、キューからの取り出しに順序付け条件が設定されている場合を除き、キューの先頭から取り出されます。priority、expiration、time がキューの順序付け条件として選択されている場合、メッセージは TPQCTL 構造体の値に従ってキューに挿入されます。順序付け条件を組み合わせて指定する場合は、最も重要な条件を最初に指定します。複数指定する場合は、カンマ (,) で区切ります。fifo または lifo (この 2 つは、相互に排他的) が指定されている場合は、この値を最後に指定します。パラメータが指定された順序によって、キューの順序付け条件が決定されます。たとえば、priority, fifo と指定されている場合、キューはメッセージの優先順位に従って取り出され、同じ優先順位のメッセージの場合は先入れ先出しで取り出されます。
管理者が順序を無視したキュー登録を有効にした場合、つまりプロンプトで top または msgid が選択されている場合、プログラマはキューの先頭、または msgid で識別されるメッセージの前にメッセージが入るように指定できます。その場合、tpenqueue 呼び出しの TPQCTL 構造体の値を使用してください。このオプションは、よく検討してから使用します。一度このオプションを設定すると、それを変更するにはキューを破棄して、再度作成する必要があります。
待機メッセージ機能の通常の動作では、メッセージをキューから取り出すトランザクションがロールバックされると、メッセージがキューに戻されます。そのメッセージがキューの先頭に到達すると、再度キューから取り出されます。必要な再試行の回数、および次の再試行までの遅延時間を指定できます。キューから取り出されたメッセージが再試行のためにキューに戻されると、キューの順序付けは遅延時間 (秒単位) だけ中断されます。この間、メッセージをキューから取り出すことはできません。
再試行回数のデフォルト値は 0 です。これは、再試行が一度も行われないことを示します。再試行回数の上限値に達すると、メッセージがキュー スペースのエラー キューに移されます。その場合、エラー キューが指定され、作成されていることが前提です。エラー キューが存在しない場合は、メッセージは破棄されます。
遅延時間には、秒単位が使用されます。メッセージ キューがすぐにいっぱいになり、キューに戻されたメッセージがすぐに先頭に達する場合、遅延要因を作成して CPU サイクルを節約することができます。再試行に関しては、使用するアプリケーションでのこれまでの経験に基づいて決定します。特定のキューに対応付けられたサービスに大量の競合がある場合、一時的な問題が多数発生します。このような問題に対処するには、再試行回数に大きな値を指定します。この値は、主観的なものです。次の再試行を行うまでの時間も同じです。ロールバックされたトランザクションで通知される問題が解消されないものである場合、再試行回数を 0 にしてメッセージを直ちにエラー キューに移動します。これは、TMQFORWARD で -d オプションを指定する場合の動作とよく似ています。ただし、長さが 0 以外の異常終了メッセージは、キューから削除するために TMQFORWARD で自動的に受信される点が異なります。
qcreate コマンドには、キューの管理を部分的に自動化する 3 つのパラメータがあります。これらのパラメータは、上下限のしきい値を設定します。しきい値は、バイト数、ブロック数、メッセージ数、またはキューの容量に対する割合 (パーセント) で表すことができます。これにより、しきい値の上限に達したときに実行されるコマンドを指定できます。実際には、コマンドはしきい値の上限に達したときに一度だけ実行され、しきい値の上限より先に下限に達しない限り、再度実行されることはありません。
キュー容量警告の上限しきい値 (b はバイト数、B はブロック数、% は使用中のパーセント値、m はメッセージ。[デフォルト値=100%%]): 80%
キュー容量警告の下限しきい値 [デフォルト値=0%]): 10%
キュー容量警告コマンド名: /usr/app/bin/mailme myqueuespace service1
この例は、しきい値の上限としてディスク ベースのキュー容量の 80% を設定し、キューの 80% が使用されたときにコマンドが実行されるように指定しています。このコマンドは、しきい値に達したときにメール メッセージを送信するように作成されたスクリプトです。myqueuespace および service1 は、このコマンドに対する仮定的な引数です。キューがいっぱいになったことが一度通知されると、その状況に対応するための操作を行うことができます。警告メッセージを再度受け取るのは、キューのロードが容量の 10% 以下になり、もう一度 80% に上がった場合だけです。永続的ではない (メモリ ベースの) キューの容量を管理するために、qcreate コマンドの -n オプションを使用して、しきい値を設定したり、コマンドが実行されるように設定することもできます。
| 注意 : | Windows マシンを使用している場合、qmadmin() セッションでコマンドを設定する方法の詳細については、「Windows 標準入出力」を参照してください。 |
2 番目の例は、もう少し自動化されていて、TMQFORWARD サーバの -e オプションを利用しています。
キュー容量警告の上限しきい値 (b はバイト数、B はブロック数、% は使用中のパーセント値、m はメッセージ。[デフォルト値=100%%]): 90%
キュー容量警告の下限しきい値 [デフォルト値=0%]): 0%
キュー容量警告コマンド名: tmboot -i 1002
この例では、キューの予備の TMQFORWARD サーバとして SRVID=1002 が設定されていること、その CLOPT パラメータに -e オプションが指定されていることが前提となっています。また、サーバが起動していないこと、または起動している場合は、キューが空であることが検出されたためにサーバが自身をシャットダウンしたことも前提となっています。キューが容量の 90% に達したとき、tmboot コマンドが実行されて予備のサーバが起動します。-e オプションを使用すると、キューが空の場合にサーバが自身を停止します。この例では、既に起動しているサーバに対して不要な tmboot コマンドを起動しないために、しきい値の下限として 0% が設定されています。
この 3 つのオプションのデフォルト値は、100%、0%、およびコマンドなしです。
キューの作成方法、およびキューの操作を行うためのパラメータの指定方法について説明してきました。これまで、メッセージが登録されるキューを作成する場合に、同じ名前のサービスでキューが処理されることが前提となっていました。キューは、ピア ツー ピア通信などほかの目的で使用される場合もあります。キュー作成時のパラメータは、キューの用途が異なっても同じものが使用されます。メッセージがサービス キューに登録される際に使用される TPQCTL 構造体には、応答キューおよび異常終了キューの名前を指定するためのフィールドがあります。TMQFORWARD は、要求されたサービスに対して TMQFORWARD が呼び出した tpacall(3c) が正常終了したか異常終了したかを検出します。そして、これらのキューが管理者によって作成されてものである場合は、その応答を設定に応じてキューに登録します。応答キューまたは異常終了キューが存在しない場合は、サービスからの正常終了または異常終了の応答メッセージは削除されます。その場合、要求の発信元であるクライアントには、キューに入れられた要求の結果に関しては、何も通知されません。サービスから応答メッセージがない場合でも、応答キューが存在するときは、TMQFORWARD によって長さ 0 のメッセージがそのキューに登録されて、要求の発信元であるクライアントに結果が通知されます。
応答キューまたは異常終了キューを作成する場合は、これらのキューからのメッセージの取り出しは、事前に登録した要求に関する情報を求めているクライアント プロセスによって行われることに注意してください。このようなメッセージをキューから取り出す一般的な方法は、そのメッセージに対応付けられている msgid (メッセージ識別子) または corrid (相関識別子) を使用することです。これは、キューの先頭からメッセージを取り出す方法と対照的です。そのため、キューの順序付け条件は、あまり意味を持ちません。その場合、fifo を設定しておけば十分です。retries パラメータおよび retry delay パラメータは、応答キューの場合は意味がないので、デフォルト値を使用してください。queue capacity のしきい値とコマンドは、応答キューでも利用できます。これらを使用して管理者に警告を通知し、管理者が対応できるようにすると便利です。
エラー キューは、システムのキューです。qspacecreate プロンプトの 1 つで、キュー スペースのエラー キューの名前を入力するように求められます。指定された名前のエラー キューが実際に作成されている場合、そのエラー キューに再試行回数の上限に達したサービス キューのメッセージが移されます。エラー キューのメッセージは、qmadmin のコマンドを使用して手動で処理することも、APPQ_MIB MIB を使用して自動化された方法で処理することもできます。このようなエラー キューの管理方法は、管理者が決定します。エラー キューには、queue capacity パラメータを使用することができます。ただし、qname を除くほかのすべての qcreate のパラメータは使用できません。
| 注意 : | エラー キューとサービス異常終了キューには、同じキューを使用しないことをお勧めします。同じキューを使用すると、アプリケーションの管理が難しくなり、クライアントが管理者の領域にまでアクセスすることも起こり得ます。 |
通常、TMQUEUE および TMQFORWARD で暗号化メッセージ バッファが処理される場合、復号化は行われません。ただし、『Oracle Tuxedo のセキュリティ機能』の「/Q との互換性および相互運用性」で説明したように、/Q コンポーネントでメッセージが登録されたバッファを復号化することが必要な場合があります。
「/Q との互換性および相互運用性」で説明したように、トランザクションに関与しない tpdequeue() 操作では、呼び出しプロセスが有効な復号化キーを持っていない場合、キューの暗号化されたメッセージが破壊されます。そのため、アプリケーションのプログラマは、暗号化されたメッセージを取り出すためにプロセスで tpdequeue() を呼び出す場合は、事前にそのプロセスの復号化キーをオープンしておく必要があります。オープンしていない場合、メッセージは失われます。
復号化キーをオープンする方法については、『Oracle Tuxedo のセキュリティ機能』の「プラグインによる復号化キーの初期化」および「暗号化されたメッセージを受信するためのコードの記述」を参照してください。
ここでは、効率的にキュー スペースを操作できるように、キューの管理者が行うべき作業について説明します。
キュー スペースのディスク ストレージを増やす必要がある場合は、qmadmin(1) の qaddext コマンドを使用します。APPQ_MIB(5) の T_APPQSPACE クラスの TA_MAXPAGES 属性を使用して、エクステントを追加することもできます。qmadmin コマンドは、キュー スペース名およびページ数を引数として取ります。ページは、QMCONFIG 変数に指定されたデバイスに対して、UDL で定義されているエクステントから割り当てられます。キュー スペースは、アクティブでないことが条件です。感嘆符を使用すると、qmadmin 外のコマンドを実行できるので、対応付けられたサーバ グループを停止できます。次に例を示します。
> !tmshutdown -g TMQUEUEGRP1
> qclose
> qaddext myqueue 100
キュー スペースは、クローズしていなければなりません。オープンしているキュー スペースにエクステントの追加を試みると、qmadmin によってそのキューがクローズします。現在キュー スペースにある永続的ではないメッセージは、qaddext コマンドが発行されて正常終了すると、すべて失われます。
キュー スペースのバックアップを作成する場合は、UNIX コマンドの dd を使用すると便利です。まず、対応付けられたサーバ グループをシャットダウンします。次のようにコマンドを入力します。
tmshutdown -g TMQUEUEGRP1
dd if=<qspace_device_file> of=<output_device_filename>
そのほかのオプションについては、UNIX システムの dd(1) リファレンス ページを参照してください。
キュー スペースをアーキテクチャが同じである別のマシンに移動する場合も、同じコマンドを使用できます。ただし、現在のデバイス名が移動先のマシンに存在しない場合は、qmadmin の chdl コマンドで開始して、新しいデバイス名を指定する必要があります。
dd コマンドを持たないサーバ プラットフォームでも、同じようなアーカイブ方法を使用できます。まず、バックアップを作成するキュー スペース、または移動するキュー スペースを含むグループをシャットダウンします。次に、アーカイブ ツールを使用して、バックアップとして使用できるファイルなどの媒体、またはキュー スペースを別のサーバに移動する際に使用されるファイルなどの媒体に、キュー スペースのデバイスを保存します。
異なるアーキテクチャ (主にバイトの並び順) を持つマシンにキュー スペースを移動する場合、その手順は複雑になります。まず、キュー スペースにあるすべてのキューからすべてのメッセージを取り出すアプリケーション プログラムを作成して実行します。次に、それらのメッセージをマシンに依存しない形式で書き出します。最後に、メッセージを新しいキュー スペースに登録します。
TMQFORWARD を使用してキューから取り出されて転送されるメッセージは、グループの境界を越えて処理されるので、グローバル トランザクション内で実行されます。リソース マネージに対応付けられていないサーバ、またはグローバル トランザクション内で実行していないサーバによってメッセージが実行される場合は、TMSNAME=TMS (NULL XA インタフェースの場合) であるサーバ グループが必要です。
メッセージが実行のためにキューから取り出された際に TMQFORWARD で開始されたグローバル トランザクションは、tpcommit() によって終了します。管理者は、コンフィグレーション ファイルに CMTRET パラメータを設定して、トランザクションのログへの記録時または完了時にトランザクションのコミットを設定できます。UBBCONFIG(5) の RESOURCES セクションの CMTRET の説明を参照してください。
トランザクション タイムアウトを処理するには、キューの管理者と、メッセージをキューから取り出すクライアント プログラムを開発するプログラマが協力することが必要です。tpdequeue(3c) が呼び出され、その flags 引数に TPQWAIT が設定されている場合、TMQUEUE サーバはメッセージがキューに到着するまで待機します。タイムアウトになるまでの時間 (秒単位) は、次の条件によって決定されます。
TPQWAIT が設定されている場合にメッセージがすぐに利用できないときは、TMQUEUE にはほかのサービス要求を処理するためのアクション リソースが必要になります。キュー スペースが同時に処理できるアクション数を増やすこともできます。その場合、qspacecreate または qspacechange コマンドに、-A actions オプションを使用します。このオプションは、同時に処理できる追加のアクション数を指定します。処理の待機中にほかのアクションを実行できる場合、条件が満たされるまでブロッキング操作は中断されます。実行できるアクションがない場合は、tpdequeue の呼び出しは失敗します。
TMQFORWARD サーバがサービスにメッセージを転送したときにそのサービスが利用できなかった場合、キューに対する再試行回数の上限に達することがあります。メッセージは、エラー キューが存在する場合はそこに移されます。このような状態を避けるには、管理者が TMQFORWARD サーバを停止するか、または再試行回数の上限値を増やします。
メッセージはエラー キューに移動されると、元のキューとは関連がなくなります。サービスが利用可能になったときに、管理者がメッセージをサービス キューに戻してエラーを修復すると、キュー名が TPQCTL 構造体の corrid に格納されて、キュー名がメッセージと対応付けられます。
「キューの容量の上限」で説明した qchange ...Queue capacity command など、qmadmin() セッション内でコンフィグレーションしたコマンドを実行するために、Windows の CreateProcess() 関数では DETACHED PROCESS として子プロセスが生成されます。このようなプロセスには、標準入出力のための関連コンソールがありません。そのため、たとえば、標準 DOS 構文で qchange ... Queue capacity command を設定して、組み込みの DOS コマンド (dir または date など) を実行し、次に標準出力をファイルにパイプまたはリダイレクトすると、コマンドが正常終了してもファイルは空です。
この問題を解決する方法として、たとえば、qchange ... Queue capacity command を実行するために、date /t > x.out コマンドでファイルの date 情報を取得します。この処理を対話的に行うには、次のような手順で実行します。
qmadmin
> qopenyourQspace> qchangeyourQname>go through all the setups... the threshold queue capacity warning,
and so on> "キュー容量警告コマンド名: " cmd /c date /t > x.out
この処理を yourFile.cmd などのコマンド ファイルから行う場合は、date /t > x.out コマンドを yourFile.cmd に追加し、次のように実行します。
qmadmin
> qopenyourQspace> qchangeyourQname>go through all the setups... the threshold queue capacity warning,> "キュー容量警告コマンド名: "
and so onyourFile.cmd
  
|