bea ホーム | 製品 | dev2dev | support | askBEA
BEA Logo Tuxedo
 ドキュメントのダウンロード   サイトマップ   用語集 
検索
0
e-docs > Tuxedo > Tuxedo CORBA ノーティフィケーション・サービス > CORBA ノーティフィケーション・サービスの管理

Tuxedo CORBA ノーティフィケーション・サービス

 Previous Next Contents Index View as PDF  

CORBA ノーティフィケーション・サービスの管理

ここでは、以下の内容について説明します。

 

はじめに

BEA Tuxedo CORBA ノーティフィケーション・サービスは、BEA Tuxedo の EventBroker システムおよびキューイング・システムに重ね合わせて使用します。つまり、CORBA ノーティフィケーション・サービスを管理する場合は、それらのほかの BEA Tuxedo システムも管理する必要があります。ノーティフィケーション・サービスの管理には、BEA Tuxedo ユーティリティの tmadmin、qmadmin、および ntsadmin を使用します。

ノーティフィケーション・サービスの管理は、コンフィギュレーションと管理という 2 つの関連するタスクで成り立ちます。それらの領域は別々に説明しますが、実際には相互に関連しています。したがって、コンフィギュレーションを完全に理解するためには、管理についても理解する必要があります (その逆も同じ)。

 

ノーティフィケーション・サービスのコンフィギュレーション

イベント・ノーティフィケーション・サービス・アプリケーションを実行するには、まず次のコンフィギュレーション要件を満たさなければなりません。

 

データ・フィルタのコンフィギュレーション

データのフィルタ処理または BEA Tuxedo ATMI 相互運用性をサブスクライバ・アプリケーションで利用する場合は、次の手順を行ってサブスクリプションでデータのフィルタ処理を利用する必要があります。

  1. フィルタ処理を行うフィールドを記述する BEA Tuxedo ATMI FML フィールド・テーブル定義ファイルを作成します (リスト7-2 を参照)。

  2. アプリケーションの起動時にフィールド定義ファイルの位置をノーティフィケーション・サービス・サーバに渡せるように、UBBCONFIG ファイルで FML フィールド・テーブル定義ファイルの配置場所を指定します (リスト7-3 を参照)。

リスト7-1 の中で、太字のコードはイベント・ポスト元アプリケーションでデータのフィルタ処理がどのようにインプリメントされるのかを示します。名前/値ペア billing および patient_account の含まれるサブスクリプションだけがイベントを受信します。

コード リスト 7-1 BEA シンプル・イベント API を使用したデータ・フィルタ処理のサンプル (C++)

 
CosNotification::StructuredEvent notif;
 
notif.header.fixed_header.event_type.domain_name =
       CORBA::string_dup("HEALTHCARE");
 
notif.header.fixed_header.event_type.type_name =
       CORBA::string_dup("HMO");
 
// このイベントの名前と値に基づいて追加フィルタを
// 指定する
 
notif.filterable_data.length(2);
notif.filterable_data[0].name = CORBA::string_dup("billing");
notif.filterable_data[0].value <<= CORBA::Long(1999);
notif.filterable_data[1].name =
          CORBA::string_dup("patient_account");
notif.filterable_data[1].value <<= CORBA::Long(2345);
 
// 構造化イベントをチャネルにプッシュ
testChannel->push_structured_event(notif);

リスト7-2 は、データのフィルタ処理を利用するために必要な FML フィールド・テーブル定義ファイルを示しています。

コード リスト 7-2 データ・フィルタ処理の FML フィールド・テーブル・ファイル

 
*base 2000
 
#Field Name      Field #  Field Type    Flags     Comments
#-----------     -------  ----------    ------    --------
billing          1        long          -         -
patient_account  2        long          -         -

リスト7-3 は、環境変数ファイル (envfile) の内容を示しています.envfile には、FML フィールド定義ファイルの位置を格納します。

注記 環境変数ファイルにはどのような名前でも使用できますが、その名前は ENVFILE コンフィギュレーション・オプション n (UBBCONFIG ファイルの SERVERS セクション) で指定された名前と同じでなければなりません。

コード リスト 7-3 データ・フィルタ処理のための envfile の指定 (Microsoft Windows)

 
FLDTBLDIR32=D:¥tuxdir¥EVENTS_Samples¥ADVANCED_Simple_cxx¥common
FIELDTBLS32=news_flds

リスト7-4 は、Advanced サンプルの UBBCONFIG ファイルで FML フィールド・テーブル・ファイルの位置がどのように指定されるのかを示しています (太字部分)。

コード リスト 7-4 UBBCONFIG ファイルでの FML フィールド定義ファイルの指定

 
*SERVERS
TMSYSEVT
  SRVGRP  = NTS_GRP
  SRVID   = 1
TMUSREVT
  SRVGRP  = NTS_GRP>>$@
  SRVID   = 2
  ENVFILE = "D:¥tuxdir¥EVENTS_Samples¥ADVANCED_Simple_CXX¥envfile"
TMNTS
  SRVGRP = NTS_GRP
  SRVID = 3 
   ENVFILE = "D:¥tuxdir¥EVENTS_Samples¥ADVANCED_Simple_CXX¥envfile"
  CLOPT = "-A -- -s TMNTSQS"
TMNTSFWD_T
  SRVGRP = NTS_GRP
  SRVID = 4 
  ENVFILE = "D:¥tuxdir¥EVENTS_Samples¥ADVANCED_Simple_CXX¥envfile"
TMNTSFWD_P
  SRVGRP = NTS_GRP
  SRVID = 5 
  ENVFILE = "D:¥tuxdir¥EVENTS_Samples¥ADVANCED_Simple_CXX¥envfile"

 

ホストとポートの設定

コールバック・オブジェクトに関するオブジェクト・リファレンスのホストとポート番号の要件は次のとおりです。

ポート番号は、動的な範囲ではなくユーザの範囲で指定します。ユーザ範囲からポート番号を割り当てることで、共同クライアント/サーバ・アプリケーションで使用するポートの不整合を回避できます。

ホストとポートを設定する方法は、プログラミング言語によって異なります。

コード リスト 7-5 Java サブスクライバ・アプリケーションでのホストとポートの設定

 
Properties prop = new Properties();
prop.put( "org.omg.CORBA.ORBClass", "com.beasys.CORBA.iiop.ORB" );
prop.put("org.omg.CORBA.ORBSingletonClass",
                 "Com.beasys.CORBA.idl.ORBSingleton");
prop.put( "org.omg.CORBA.ORBPort",  nnnn );
ORB orb = ORB.init(args, prop);

注記 java コマンド行でポートを設定することもできます。ポート番号を設定する java コマンド行の例を次に示します。

java -DTOBJADDR=//BEANIE:2359 ¥ -Dorg.omg.corba.ORBPort=portnumber -classpath...

 

トランザクション・ログの作成

永続的なサブスクリプションを使用する場合は、BEA Tuxedo キューイング・システムをコンフィギュレーションおよび起動する必要があります。キューイング・システムでは、トランザクション・ログが必要です。リスト7-6 は、tmadmin ユーティリティを使用してトランザクション・ログを作成する方法を示しています。

コード リスト 7-6 トランザクション・ログの作成 (createtlog) (Microsoft Windows)

 
>tmadmin
 
>crdl -b 100 -z D:¥tuxdir¥EVENTS_Samples¥ADVANCED_Simple_CXX¥TLOG
>crlog -m SITE1
>quit
>

 

イベント・キューの作成

永続的なイベントを使用する場合は、BEA Tuxedo キューイング・システムをコンフィギュレーションおよび起動する必要があります。次の 2 つのイベント・キューを作成しなければなりません。

これらのキューをコンフィギュレーションするには、次の手順を行います。

  1. キュースペースのデバイスをディスク上に作成します。

  2. キュースペースをコンフィギュレーションします。

  3. キューを作成します。

上記の手順については、以下の節を参照してください。

一時的および永続的なサブスクリプションのスペース・パラメータの値の割り出し

システムを調整して最大限の性能を引き出すためには、次のパラメータの最適な値を割り出す必要があります。

一時的なサブスクリプションの IPC キュースペース

一時的なサブスクリプションのスペース・パラメータの値は次のように割り出します。

  1. 一時的なサブスクリプションのパイプラインを通る可能性のあるイベントの数、つまり特定の時点で配信されている可能性のあるイベントの数を割り出します。この数は、イベントの数とそれらのイベントを受信するサブスクライバの数を乗算すると算出できます。

  2. イベントのサイズを割り出します。説明の便宜上、イベントは比較的小さく約 300 バイト以下と想定します。

  3. 起動する必要のある一時的な転送サーバの数を割り出します (たいていは 1 つか 2 つ)。マシン上のプロセッサごとに 1 つから始めるのが理想的です。

  4. 一時的なイベントを保持するのに必要な IPC キュースペースの量を割り出します。必要なスペースの量は、1000 バイトをパイプラインで許容するイベント数で乗算した値です。この値は、一時的な転送サーバの IPC キューの数で除算します。MSSQ セットを使用する場合は、1 つの IPC キューが一時的な転送サーバで共有されます。使用しない場合は、各転送サーバで独自の IPC キューが使用されます。

    たとえば、10 のイベントが 50 のサブスクライバにパイプラインで配信されると仮定し、2 つの一時的な転送サーバを起動して、それらのサーバで IPC キューが共有されないとすると (つまり MSSQ は不使用)、IPC キュースペースの必要量は次のようになります。

    10 イベント * 50 サブスクライバ * 1000 バイト / 2 転送サーバ = 250,000 バイト

  5. システム・レジストリのエントリを変更して、IPC キューのサイズをこの値にコンフィギュレーションします。その方法はプラットフォームによって異なります。

永続的なサブスクリプションの /Q キュー・サイズ・パラメータ

永続的なサブスクリプションのスペース・パラメータの値は次のように割り出します。

  1. 永続的なサブスクリプションのパイプラインを通る可能性のあるイベントの数、つまり特定の時点で配信されている可能性のあるイベントの数を割り出します。この数は、イベントの数とそれらのイベントを受信するサブスクライバの数を乗算すると算出できます。

  2. イベントのサイズを割り出します。説明の便宜上、イベントは比較的小さく約 300 バイト以下と想定します。

  3. 永続的なイベントを保持するのに必要な /Q キューのサイズを割り出します (保留キューとエラー・キューの両方)。次のように割り出します。

    1. ディスク・ページのサイズを割り出します。それはプラットフォームによって異なります。たとえば Microsoft Windows の場合、ディスク・ページは 500 バイトです。UNIX マシンの場合、ディスク・ページのサイズは 500 〜 4000 バイトです。

    2. 1 つのイベントを格納するのに必要なディスク・ページの数を割り出します。たとえば、イベントごとに 1000 バイトが必要で、ディスク・ページのサイズが 500 バイトである場合は、イベントごとに 2 つのディスク・ページが必要になります。

    3. イベント全体で必要なディスク・ページの数を割り出します。たとえば、500 の保留イベントと 200 のエラー・イベントを許容し、1 つのイベントが 2 つのディスク・ページを占める場合は、1400 のディスク・ページが必要になります。

    4. qspace で必要なディスク・ページの数を割り出します。これは、イベントに必要なディスク・ページと qspace のオーバーヘッドのためのページの合計数です。たとえば、イベントで 1400 のディスク・ページが必要な場合、qspace では約 1450 のディスク・ページが必要です (50 ページはオーバーヘッド用)。

    5. qspace デバイスで必要なページ数を割り出します。これは、qspace に必要なディスク・ページとデバイスのオーバーヘッドのためのページの合計数です。たとえば、qspace で 1450 のディスク・ページが必要な場合、デバイスでは約 1500 のディスク・ページが必要です (50 ページはデバイスのオーバーヘッド用)。

  4. qmadmin を使用して永続的なイベントの qspace を作成する場合は、まず最初にデバイスを作成します。サイズは、ステップ 3e で算出された値を使用します (約 1500 ページ)。次に、qspace のサイズを指定します。サイズは、ステップ 3d で算出された値を使用します (約 1450 ページ)。次に、保留キューおよびエラー・キューに存在できるイベントの数を指定します。以降の節では、qspace を作成およびコンフィギュレーションする方法を説明します。

ディスク上のキュースペースのデバイスの作成

qmadmin コマンド・ユーティリティを使用すると、ディスク上にキュースペースのデバイスを作成できます。

キュースペースを作成するには、まず汎用デバイス・リスト (UDL) でそのエントリを作成する必要があります。リスト7-7 は、コマンドの例を示しています。

コード リスト 7-7 ディスク上のキュースペースのデバイスの作成 (UNIX)

 
prompt>qmadmin d:¥smith¥reg¥QUE
qmadmin - Copyright (c) 1996-1999 BEA Systems, Inc.
Portions * Copyright 1986-1997 RSA Data Security, Inc.
All Rights Reserved.
Distributed under license by BEA Systems, Inc.
BEA Tuxedo is a registered trademark.
QMCONFIG=d:¥smith¥reg¥QUE
 
> crdl d:¥smith¥reg¥QUE 0 1100
Created device d:¥smith¥reg¥QUE, offset 0, size 1100
 on d:¥smith¥reg¥QUE

ディスク上でデバイスを作成する方法の詳細については、『BEA Tuxedo/Q コンポーネント』を参照してください。

キュースペースのコンフィギュレーション

キュースペースをコンフィギュレーションするには、qmdamin qspacecreate コマンドを使用します。キュースペースでは、IPC 資源が使用されます。そのため、キュースペースを定義する場合は、共用メモリ・セグメントとセマフォを割り当てることになります。qspacecreate コマンドを使用する最も簡単な方法は、プロンプトを表示することです。リスト7-8 は、Advanced サンプル・アプリケーション用にコンフィギュレーションされたキュースペースの例を示しています。

コード リスト 7-8 キュースペースの作成

 
> qspacecreate
Queue space name: TMNTSQS
IPC Key for queue space: 52359
Size of queue space in disk pages: 1050
Number of queues in queue space: 2
Number of concurrent transactions in queue space: 10
Number of concurrent processes in queue space: 10
Number of messages in queue space: 500
Error queue name: TMNTSFWD_E
Initialize extents (y, n [default=n]): y
Blocking factor [default=16]:

リスト7-8 で作成されるキュースペースでは、次のサイズ設定に注意してください。

Number of messages in queue space:500

このパラメータを 500 に設定すると、保留キューとエラー・キューで合計 500 のイベントを格納するスペースが確保されます。

Size of queue space in disk pages:1050

Microsoft Windows では、各ディスク・スペースのサイズが 500 バイトで、各イベントは 1000 バイトが必要です。その上、イベントごとに 2 つのディスク・ページを供給する必要があります。保留キューとエラー・キューに 500 のイベントが格納されると見積もっているので、1000 のディスク・ページを供給しなければなりません。また、qspace のオーバーヘッドのために 50 のディスク・ページが必要なので、qspace のサイズは 1050 ディスク・ページに設定します。最後に、デバイスのオーバーヘッドでも 50 のディスク・ページが必要なので、デバイスのサイズは 1100 ディスク・ページになります。この値は、crdl コマンドを使用して設定します (リスト7-7 を参照)。

キュースペース作成の詳細については、『BEA Tuxedo/Q コンポーネント』を参照してください。

キューの作成

使用する各キューを作成するには、qmadmin qcreate コマンドを使用します。キューを作成するには、まず qmadmin qopen コマンドでキュースペースを開く必要があります。キュースペース名が指定されていない場合は、qopen で名前を入力するように求められます。

リスト7-9 は、Advanced サンプル・アプリケーション用に作成される TMNTSFWD_P キューと TMNTSFWD_E キューの作成例を示しています。

コード リスト 7-9 キューの作成

 
> qopen
Queue space name: TMNTSQS
 
> qcreate
Queue name: TMNTSFWD_P
Queue order (priority, time, fifo, lifo): fifo
Out-of-ordering enqueuing (top, msgid, [default=none]): none
Retries [default=0]: 5
Retry delay in seconds [default=0]: 3
High limit for queue capacity warning (b for bytes used, B for
 blocks used, % for percent used, m for messages [default=100%]):
 80%
Reset (low) limit for queue capacity warning [default=0%]: 0%
Queue capacity command:
No default queue capacity command
Queue 'TMNTSFWD_P' created
 
> qcreate
Queue name: TMNTSFWD_E
Queue order (priority, time, fifo, lifo): fifo
Out-of-ordering enqueuing (top, msgid, [default=none]): none
Retries [default=0]: 2
Retry delay in seconds [default=0]: 30
High limit for queue capacity warning (b for bytes used, B for
 blocks used, % for percent used, m for messages [default=100%]):  
 80%
Reset (low) limit for queue capacity warning [default=0%]: 0%
Queue capacity command:
No default queue capacity command
Q_CAT:1438: INFO: Create queue - error queue TMNTSFWD_E created
Queue 'TMNTSFWD_E' created
 
> q

キュー作成の詳細については、『BEA Tuxedo/Q コンポーネント』を参照してください。

Microsoft Windows での IPC パラメータの設定

Microsoft Windows システム向けの BEA Tuxedo ソフトウェア製品には、プロセス間通信のサブシステムである BEA Tuxedo IPC Helper (TUXIPC) が同梱されています。IPC Helper はほとんどのマシンではインストール時の設定で実行されますが、コントロール・パネル・アプレットにある [IPC Resources] ページを使用して、TUXIPC サブシステムを調整し、性能を最大化することもできます。

[IPC] コントロール・パネルの [IPC Resources] ページを表示するには、次の手順を行います。

  1. [スタート] メニューの [設定] をポイントし、[コントロール パネル] を選択します。Microsoft Windows のコントロール・パネルが表示されます (図0-1)。

    図 0-1 Microsoft Windows のコントロール・パネル


     


     

  2. [BEA Administration] アイコンをクリックします。[BEA Administration] コントロール・パネルが表示されます (図0-2)。

  3. [IPC Resources] タブをクリックします。[BEA Administration] コントロール・パネルの [IPC Resources] コントロール・パネル部分が表示されます (図0-2)。

    図 0-2 Microsoft Windows 向け BEA Tuxedo ソフトウェアの [IPC Resources] コントロール・パネル


     

BEA Tuxedo マシンの IPC 設定を定義するには、次の手順を行います。

  1. [Current Resource: Default] ボックスで、[Use Default IPC Settings] チェック・ボックスをクリックしてクリアします。

  2. 挿入ボックスをクリックします。

  3. マシンの名前を入力して Enter キーを押します。

  4. 設定する IPC 資源の横にあるフィールドをクリックし、必要な値を入力して、[Apply] をクリックします。[Apply] をクリックすると、変更が登録テーブルに保存されます。変更内容を有効にするには、tuxipc.exe サービスを一度終了してから再起動します。

  5. [OK] をクリックしてコントロール・パネルを閉じます。

実行中の BEA Tuxedo サーバ・アプリケーションのパフォーマンスは、パフォーマンス・モニタで確認できます。

パフォーマンス・モニタを起動するには、
[スタート] メニューの [プログラム] をポイントし、[管理ツール] の [パフォーマンス モニタ] を選択します。パフォーマンス・モニタの画面が表示されます (図0-3)。

図 0-3 Microsoft Windows 向け BEA Tuxedoソフトウェアのパフォーマンス・モニタ


 

 

UBBCONFIG ファイルと TUXCONFIG ファイルの作成

イベントのポスト元アプリケーションとサブスクライバ・アプリケーションが BEA Tuxedo ドメインの CORBA オブジェクト (この場合はノーティフィケーション・サービス) と通信するためには、ノーティフィケーション・サービスで UBBCONFIG ファイルが必要です。UBBCONFIG ファイルは、ノーティフィケーション・サービス・アプリケーションの開発の過程で記述する必要があります。そうしないと、アプリケーションをビルドして実行することができません。

UBBCONFIG ファイルを記述した後は、tmloadcf コマンドを使用して TUXCONFIG ファイル (実行時に使用) を生成します。したがって、TUXCONFIG ファイルはノーティフィケーション・サービス・アプリケーションの起動前に存在していなければなりません。TUXCONFIG ファイルは、バイナリ形式の UBBCONFIG ファイルです。tmloadcf コマンドの使用例を次に示します。

 
tmloadcf -y ubb

UBBCONFIG ファイルを記述する前に、ノーティフィケーション・サービス・アプリケーションのコンフィギュレーション要件をリストしておく必要があります。要件をリストするためには、サブスクリプションをサポートするために必要なサーバとプロセスを特定します。表 7-1 は、異なるタイプのサブスクリプションのコンフィギュレーション要件を示しています。

表 7-1 一時的および永続的なサブスクリプションのコンフィギュレーション要件

サポート対象のサブスクリプション

UBBCONFIG ファイルに含まれなければならないサーバとプロセス

一時的なサブスクリプション

TMUSREVT、TMNTS、および TMNTSFWD_T

永続的なサブスクリプション

TMUSREVT、TMNTS、TMNTSFWD_P、TMQUEUE, TMQFORWARD


 

IIOP が使用されるイベント・サブスクライバ・アプリケーションを使用する場合は、IIOP ハンドラ (ISH) に接続されていないコールバック・オブジェクトを呼び出せるようにアウトバウンド IIOP を有効にするパラメータで、UBBCONFIG ファイルの IIOP リスナ (ISL) コマンドをコンフィギュレーションする必要があります。ISL コマンドの -O オプション (大文字の O) はアウトバウンド IIOP を有効にします。追加パラメータを使用すると、システム管理者はノーティフィケーション・サービス・アプリケーションの最適なコンフィギュレーションを取得できます。ISL コマンドの詳細については、『BEA Tuxedo アプリケーションの設定』を参照してください。

ノーティフィケーション・サービス・アプリケーションを開発するときには、UBBCONFIG ファイルの SERVERS セクションで次のタイプのサーバを設定できます。

リスト7-10 は、ノーティフィケーション・サービスの Introductory サンプル・アプリケーションの UBBCONFIG ファイルです。Introductory サンプル・アプリケーションでは一時的なサブスクリプションのみがサポートされており、永続的なサブスクリプションまたはデータのフィルタ処理はサポートされていません。

コード リスト 7-10 Introductory サンプルの UBBCONFIG ファイル

 
# この UBBCONFIG ファイルは一時的なサブスクリプションのみをサポートし、
# 永続的なサブスクリプションまたはデータのフィルタ処理はサポートしない
*RESOURCES
    IPCKEY 52359
    DOMAINID events_intro_simple_cxx
    MASTER SITE1
    MODEL SHM
#---------------------------------------------------------------
*MACHINES
    "BEANIE"
        LMID = SITE1
    APPDIR = "D:¥tuxdir¥EVENTS~1¥INTROD~2"
    TUXCONFIG = "D:¥tuxdir¥EVENTS~1¥INTROD~2¥tuxconfig"
    TUXDIR = "d:¥tuxdir"
    MAXWSCLIENTS = 10
    ULOGPFX = "D:¥tuxdir¥EVENTS~1¥INTROD~2¥ULOG"
#----------------------------------------------------------------
# 一時的なイベントを使用するので、グループがトランザクション
# に関与する必要はない
*GROUPS
    SYS_GRP
    LMID = SITE1
    GRPNO = 1 
#---------------------------------------------------------------
*SERVERS
    DEFAULT:
    CLOPT = "-A"
    TMSYSEVT
    SRVGRP = SYS_GRP
    SRVID = 1 
TMUSREVT
    SRVGRP = SYS_GRP
    SRVID = 2 
TMFFNAME
    SRVGRP = SYS_GRP
    SRVID = 3 
    CLOPT = "-A -- -N -M"
TMFFNAME
    SRVGRP = SYS_GRP
    SRVID = 4 
    CLOPT = "-A -- -N"
TMFFNAME
    SRVGRP = SYS_GRP
    SRVID = 5 
    CLOPT = "-A -- -F"
# ノーティフィケーション・サービス・サーバを起動
#
TMNTS
    SRVGRP = SYS_GRP
    SRVID = 6 
# ノーティフィケーション・サービスの一時的なイベント転送サーバを起動
#
TMNTSFWD_T
    SRVGRP = SYS_GRP
    SRVID = 7 
# Start the ISL with -O since we are using callbacks to clients.
ISL
    SRVGRP = SYS_GRP
    SRVID = 8 
    CLOPT = "-A -- -O -n //BEANIE:2359"
#---------------------------------------------------------------
*SERVICES

リスト7-11 のコード例は、ノーティフィケーション・サービスの Advanced サンプル・アプリケーションからの引用です。Advanced サンプル・アプリケーションでは、一時的なサブスクリプションと永続的なサブスクリプションおよびデータのフィルタ処理がサポートされています。

コード リスト 7-11 Advanced サンプルの UBBCONFIG ファイル

 
# この UBBCONFIG ファイルは一時的なサブスクリプションと永続的な
# サブスクリプションおよびデータのフィルタ処理をサポートする
*RESOURCES
    IPCKEY 52363
    DOMAINID events_advanced_simple_cxx
    MASTER SITE1
    MODEL SHM
#---------------------------------------------------------------
*MACHINES
    "BEANIE"
        LMID = SITE1
    APPDIR = "D:¥tuxdir¥EVENTS~1¥ADVANC~1"
    TUXCONFIG = "D:¥tuxdir¥EVENTS~1¥ADVANC~1¥tuxconfig"
    TUXDIR = "d:¥tuxdir"
    MAXWSCLIENTS = 10
    ULOGPFX = "D:¥tuxdir¥EVENTS~1¥ADVANC~1¥ULOG"
#
#  永続的なイベントを使用するので、トランザクション・ログが必要
#
    TLOGDEVICE = "D:¥tuxdir¥EVENTS~1¥ADVANC~1¥TLOG"
    TLOGSIZE = 10
#---------------------------------------------------------------
*GROUPS
    SYS_GRP
    LMID = SITE1
    GRPNO = 1 
#  ノーティフィケーション・サービス・サーバのヌル・トランザクション
#  ・グループを作成する
#
NTS_GRP
    LMID = SITE1
    GRPNO = 2 
    TMSNAME = TMS
    TMSCOUNT = 2 
#  永続的なイベントを使用するので、永続的なキューが必要
#  キュー・サーバのキュー・トランザクション・グループを作成
#
QUE_GRP
    LMID = SITE1
    GRPNO = 3 
    TMSNAME = TMS_QM
    TMSCOUNT = 2 
#
#  作成した QUE スペースをキュー・グループに管理させる
#  TMNTSQS として指定するキュースペースの名前は、作成したキュースペース #  の名前と同じでなければならない
#
   OPENINFO = "TUXEDO/QM:D:¥tuxdir¥EVENTS~1¥ADVANC~1¥QUE;TMNTSQS"
#---------------------------------------------------------------
*SERVERS
    DEFAULT:
    CLOPT = "-A"
#
#  キュー・サーバを起動
#  CLOPT の -s オプションで指定するキュースペースの名前は、
#  作成したキュースペースの名前と同じでなければならない
#
TMQUEUE
    SRVGRP = QUE_GRP
    SRVID = 1 
    CLOPT = "-s TMNTSQS:TMQUEUE --  "
#
#  キュー転送サーバを起動し、イベントをノーティフィケーション・サービス
 
#  の永続的な転送サーバに転送させる
#
TMQFORWARD
    SRVGRP = QUE_GRP
    SRVID = 2 
    CLOPT = "-- -i 2 -q TMNTSFWD_P"
    TMSYSEVT
    SRVGRP = NTS_GRP
    SRVID = 1 
#
#  ユーザ EventBroker を起動する。ユーザ EventBroker が
#  「Story」fml フィールドの定義を見つけることができるよ
#  うに環境ファイルを渡す。これで、ユーザ EventBroker が
#  ファイルを渡す
#
TMUSREVT
    SRVGRP = NTS_GRP
    SRVID = 2 
    ENVFILE = "D:¥tuxdir¥EVENTS~1¥ADVANC~1¥envfile"
TMFFNAME
    SRVGRP = SYS_GRP
    SRVID = 1 
    CLOPT = "-A -- -N -M"
TMFFNAME
    SRVGRP = SYS_GRP
    SRVID = 2 
    CLOPT = "-A -- -N"
TMFFNAME
    SRVGRP = SYS_GRP
    SRVID = 3 
    CLOPT = "-A -- -F"
#
#  ノーティフィケーション・サービス・サーバを起動する。
#  ノーティフィケーション・サーバがデータのフィルタ処理を実行
#  できるように環境ファイルを渡す。永続的なイベントを使用するので、
#  -s オプションを指定しなければならない。-s オプションは、TMNTSQS
#   としてキュースペースの名前を指定する。この名前は作成したキュー
#   スペースの名前と同じでなければならない
#
TMNTS
    SRVGRP = NTS_GRP
    SRVID = 3 
    ENVFILE = "D:¥tuxdir¥EVENTS~1¥ADVANC~1¥envfile"
    CLOPT = "-A -- -s TMNTSQS"
#
#  ノーティフィケーション・サービスの一時的なイベント転送サーバを
#  起動する。サーバがデータのフィルタ処理を実行できるように環境
#  ファイルを渡す
#
 
TMNTSFWD_T
    SRVGRP = NTS_GRP
    SRVID = 4 
    ENVFILE = "D:¥tuxdir¥EVENTS~1¥ADVANC~1¥envfile"
#
#  Start the notification service persistent event forwarder.
#  Pass in the environment file so that the server can perform
#  data filtering.
#
TMNTSFWD_P
    SRVGRP = NTS_GRP
    SRVID = 5 
    ENVFILE = "D:¥tuxdir¥EVENTS~1¥ADVANC~1¥envfile"
#
#  Start the ISL with -O since we're using callbacks to clients.
#
ISL
    SRVGRP = SYS_GRP
    SRVID = 4 
    CLOPT = "-A -- -O -n //BEANIE:2363"
#---------------------------------------------------------------
*SERVICES

 

ノーティフィケーション・サービスの管理

ノーティフィケーション・サービス・アプリケーションをデプロイした後は、次の管理タスクを継続的に実行する必要があります。

  1. データベースの同期

  2. システムからのデッド・サブスクリプションのパージ

  3. キュー使用率の監視

  4. キューからの不要なイベントのパージ

  5. エラー・キューのイベントの移動または削除

データベースの同期

複数の EventBroker をコンフィギュレーションする場合は、ノーティフィケーション・サービスのサブスクリプション・データベースで同期を取る必要があります。同期プロセスは時間を要し (イベントの配信に影響することがある)、ネットワーク・トラフィックを増大させるので、イベントのトラフィックが要求しない限りは複数の EventBroker をコンフィギュレーションしないでください。

複数の EventBroker をコンフィギュレーションするときには、TMUSREVT サーバの -P オプションを使用してデータベースの同期に要する時間をコンフィギュレーションできます。このオプションの設定方法については、『BEA Tuxedo のファイル形式とデータ記述方法』の TMUSREVT(5) を参照してください。

注記 データベースの同期に要する時間は、サブスクライバがサブスクライブしてからイベントを受信するまでの所要時間に影響します。また、サブスクライバがアンサブスクライブしてからイベントの受信が停止されるまでの所要時間にも影響します。

システムからのデッド・サブスクリプションのパージ

サブスクリプションは、サブスクライバが永続的なサブスクリプションを作成し、アンサブスクライブせずにシャットダウンしてから、再起動することなくノーティフィケーション・サービスに再接続しなかった場合、またはサブスクライバがどのイベントとも一致しないサブスクリプションを作成した場合にデッド状態になります。サブスクライバでは永続的なサブスクリプションを作成してから、アンサブスクライブせずにシャットダウンすることができますが、定期的に再接続して蓄積されたイベントを取得しないとエラーになります。ノーティフィケーション・サービスでは永続的なサブスクリプションと一致するイベントの配信が定期的に試行されるので、そのようなイベントはサブスクライバが接続されていない間蓄積され、キュースペースを消費し、システム・リソースを浪費します。

どのイベントとも一致することのないサブスクリプションは、意味を成さないので作成しないようにしてください。また、ポストされた各イベントは各サブスクリプションと照合しなければならないので、サブスクリプションはシステム・リソースを消費します。

表 7-2 の ntsadmin コマンドを使用すると、すべてのサブスクリプションを表示し、各サブスクリプションの保留キューとエラー・キューにどのくらいの数のイベントが入っているのかを確認できます。また、ntsadmin コマンドを使用してサブスクリプションを削除したり、エラー・キューのイベントを保留キューに移動したりすることもできます。ntsadmin ユーティリティの詳細については、第 7 章の 32 ページ「ntsadmin」を参照してください。

表 7-2 ntsadmin コマンドの概要

コマンド

説明

subscriptions

サブスクリプション・データベースにあるサブスクリプションをリストします。

rmsubscriptions

サブスクリプション・データベースのサブスクリプションを削除します。

pendevents

保留イベント・キューにあるイベントの情報を表示します (永続的なサブスクリプションのみ)。

rmpendevents

保留イベント・キューのイベントを削除します (永続的なサブスクリプションのみ)。

errevents

イベント・エラー・キューのイベントをリストします (永続的なサブスクリプションのみ)。

rmerrevents

イベント・エラー・キューのイベントを削除します (永続的なサブスクリプションのみ)。

 

自動的にデッド・サブスクリプションを検出する手段はありませんが、ntsadmin ユーティリティを利用して、サブスクリプションがデッド状態かどうか、いつデッド状態になるのかを判断することはできます。

キュー使用率の監視

キューは、固定量のスペースを割り当てて作成します。このスペースは、イベントが蓄積されるにつれて消費されていきます。キューが一杯になると、それ以降はイベントをキューに入れることはできません。

キューの使用率を監視するには、qmadmin または ntsadmin を使用します (『BEA Tuxedo コマンド・リファレンス』の qmadmin(1) を参照)。

保留イベントを保持するためにキュースペースが作成されたときには、そのキュースペースで保持できるイベントの最大数が指定されました。たとえば、Advanced サンプル・アプリケーションでは、TMNTSQS キュースペースのイベントの最大数は 200 に設定されました (第 7 章の 8 ページ「イベント・キューの作成」 を参照)。キュースペースの容量がわかっていれば、ntsadmin pendevents コマンドを使用してイベント・キューで保留されているイベントの数を確認できます。イベント・キューが一杯であるか、一杯に近い場合は、イベント最大数の設定を増やすか、イベント・キューの数を増やす必要があります。

注記 qmadmin qcreate コマンドでしきい値コマンド・オプション (cmd) を使用すると、キューがいっぱいに近くなったときに警告を生成することができます。このコマンドの詳細については、『BEA Tuxedo コマンド・リファレンス』の qmadmin(1) を参照してください。

キューからの不要なイベントのパージ

ntsadmin コマンドの rmerrevents および rmpendevents を使用すると、保留キューまたはエラー・キューからイベントをパージできます。

警告 キューからイベントを削除した後は、そのイベントを復元することはできません。イベントは完全に消滅し、サブスクライバ・アプリケーションがそのイベントを受信することはありません。

エラー・キューの管理

イベントの配信が事前に設定された回数試行された後、そのイベントはエラー・キューに移動します。イベントがエラー・キューに移動されたら、管理者はシステムからそのイベントをパージするか、そのイベントを保留キューに戻さなければなりません。イベントのパージについては、前節で説明しています。

エラー・キューから保留キューにイベントを移動するということは、イベント配信の再開を要求するということです。イベント配信の失敗はシステム・リソースを消費するので、配信の障害となっていた状況が修正されている場合以外は保留キューにイベントを戻さないでください。イベントを保留キューに戻すには、ntsadmin retryerrevents コマンドを使用します。

 

ノーティフィケーション・サービスの管理ユーティリティとコマンド

ここでは、以下の内容について説明します。

ntsadmin ユーティリティ

この節では、ntsadmin ユーティリティについて説明します。

 

Back to Top Previous Next
dev2devesupportedocs.bea.compartner net
Contact e-docsContact BEAwebmasterprivacy