OpenVOS オペレーティングシステムは、高レベルのアプリケーション・プログラミング・インタフェース (API) を提供しており、全体的にシステムのプログラミングを容易にします。 しかし、時には簡単すぎることもあります - s$...ルーチンへの単純なサブルーチン呼び出しが、多くの複雑さを隠しているかもしれないからです。 ユーザーは、単純な呼び出しが多くの作業につながり、システムやアプリケーションに問題を引き起こす可能性があることに気づかないことがあります。
アプリケーションデザインで避けてしまいそうな落とし穴に注意を促す不定期連載の第2回目です。
サーバキューのための list_messages の弊害
OpenVOS の list_messages コマンドは、OpenVOS のトランザクション保護製品の一部であるキューで使用することを意図しています。 StrataDOCfor OpenVOS は、このコマンドが "与えられたキューにあるメッセージに関する情報を表示する" ことを示しています。 そのため、本番環境でキューのバックアップを開始したときに、このコマンドを使ってキューにどれだけのメッセージがあるのかを調べたくなるかもしれません。 totals_only オプションは、必要なものと同じように見えます。 このコマンドがどのように動作するかを理解すれば、なぜこれが良い選択ではないのかが理解できるでしょう。
list_messages コマンドの操作方法
このコマンドはファイルにポートをアタッチし、そのポートを SERVER_TYPE (あるいは一方通行のサーバキューの場合は RECV_ONLY_SRV_TYPE) として開き、no_wait_mode にします。 キューがトランザクション保護されている場合は、コマンドは優先度 -1 でトランザクションを開始し、これは競合がある場合には常に負けることを意味し、終了すると s$abort_transaction を呼び出します。
次に、キューの最初のレコードから始まり、s$read_msgを呼び出して、受信可能なすべてのレコードをカウントしてから、そのレコードをカウントしたり、出力ポートにダンプしたりします。
各メッセージに関する情報を表示するためには、メッセージの元となったモジュールとプロセスに関する情報を検索する必要があります。
最後に、キューで見つけたレコードの合計を表示します。
そのアプローチの問題点
このコマンドは、メッセージがキューに入っている間にメッセージを見て、 メッセージが適切にフォーマットされ、適切なフィールドを含んでいるかどうか、 正しい優先度でキューに入っているかどうか、サーバに受信されているかどうかなどを判断するために、 アプリケーション開発のプログラマが使用することを意図していました。 しかし、他の目的でコマンドを使用した場合には、多くの制限があったり、データが隠されていたり、ミスリードしていたりすることがあります。
- キュー内のメッセージに関する情報を取得するには、キューへの実行、読み込み、または書き込みのいずれかのアクセス権を持っている必要があります。キューへの実行アクセスまたは読み込みアクセスを持っている場合は、自分のメッセージに関する情報のみを取得することができます。書き込みアクセスを持っている場合は、すべてのメッセージに関する情報を取得することができます。
- キューがサーバキューの場合、 list_messages は、サーバからまだ返信されていないメッセージのみをリストアップします。返信されたメッセージのうち、 s$msg_receive_reply によってキューから削除されていないメッセージはリストに含まれません。
- しかし、すべてのメッセージが未受信の返信である場合、 list_messages はキュー内のメッセージをゼロと表示するかもしれません。
- list_messages コマンドは、メッセージを取得している間、キューのサーバとして現れるので、キューにサービスを提供しているサーバの数を クライアントや他の制御プロセスに誤魔化してしまう可能性があります。
- リクエスターのプロセスに関するモジュールやプロセスの情報を取得するには、リクエスターが別のモジュール上にいる場合、ネットワークトランザクションが必要になることがあります。
- 各メッセージは、メッセージを読むためにカーネルへのトリップを必要とします。 キューを所有しているモジュールからコマンドを実行しない場合は、各メッセージを読むためにネットワークトランザクションが必要です。
- totals_only を指定した場合でも、各メッセージを読み込んでカウントする必要があります。
- totals_onlyによって表示される値は、サーバにキューイングされているか、サーバによって処理されているメッセージに対してのみ表示されます。 待ち行列に残っている双方向サーバキューメッセージに対する未受信の返信については何も表示されないため， -totals_only の値は誤解を招きやすい。
- メッセージ内のデータは、機密情報（クレジットカードの口座番号など）である可能性があります。
異なる方法
1990 年には、新しい API が提供されました: s$get_server_queue_info。 キューのパス名が与えられると、このルーチンは
- server_queueの種類(一方通行か双方向か)
- メッセージ数
- 暇でないメッセージの数
- 最高のメッセージ数
- 処理されたメッセージの総数です。
- このキューの設定された最大メッセージ数(max_queue_depth)。
このルーチンは list_messages よりも多くの利点があります。
- 合計情報を取得するためのカーネルへの一回のトリップ、および/またはネットワークを介した一回のトリップ。
- 未読の返信を含めたあらゆるメッセージの考察。
- キューの混乱はありません。 キューヘッダは、キューヘッダから 5 つのカウンタの一貫したセットを得るのにちょうど十分な長さのマイクロ秒の間ロックされます。
- 依頼元としてキューを開いた際に情報を取得することができます。
check_queue_depth コマンド
何年も前にcheck_queue_depthというコマンドを書きましたが、このインターフェースを使ったコマンドを使うと、1つ以上のキューに対してこの情報を表示するだけでなく、しきい値に達したときに監視や警告ができるようになります。
check_queue_depth queues [-warn_percent数] [-interval数]
[-notify user_name] [-brief] [-long]
[-ignore_invalid_type] [-syserr]
[-exit_after_warning]
コマンドのソースコードは、Stratus Public FTP サイトで公開されています。
- ドキュメント http://ftp.stratus.com/vos/perf/check_queue_depth.txt
- ソースコード http://ftp.stratus.com/vos/perf/check_queue_depth.pl1
自由に使用したり、強化したり、アプリケーションの監視コマンドに組み込んだりしてください。