JP2010086137A - メッセージキューイング方法及びプログラム - Google Patents

Abstract

【課題】プロセス起動時の他プロセスへの影響を排除できる冗長化されたアプリケーションへのメッセージキューイング方法及びプログラムを提供する。
【解決手段】メッセージ処理装置１のメッセージキュー部１０は受信したメッセージを保存する。メッセージ受信制御部１１は、メッセージ１００の宛先の通知を受け、プロセスの現用又は待機を記録したプロセス制御表１１０に基づいて、現用プロセスに対するメッセージ１００のみを取り出し、対応する現用プロセスのアプリケーション２Ｂへメッセージ１００を送信する。一方、メッセージ受信制御部１１は、待機プロセスのアプリケーション２Ｂに対しては、メッセージ１００を送信しない。
【選択図】図１

Description

本発明は、メッセージキューイング方法及びプログラムに関し、特に、冗長化されたアプリケーションの連携を行うアプリケーション間におけるメッセージキューイング方法及びプログラムに関する。

株式取引システム等のような運用停止が不可とされるコンピュータシステムは、ミッションクリティカルであるという。このようなミッションクリティカルなコンピュータシステムにおいては、その信頼性を高めるため、コンピュータシステムを冗長化する必要がある。このようなシステムの冗長化に関する技術としては、以下の方法がある。

第１の方法は、アプリケーションのプロセス単位での冗長化を行う方法である。この方法は、プロセスの実行多重度が一定になるようにプロセス数を補充する方法、即ち、アプリケーションの２つ以上のプロセスを用意し、プロセス単位でのホットスタンバイ構成とする方法である。具体的には、同じ構成のシステムを２系統用意しておき、一方のシステムを現用系として動作させて、他方は待機系として同じ動作をさせながら、待機状態にしておく方法である。待機系のシステムは、現用系のシステムと常に同じ状態を保ち、現用系のシステムに障害が発生した場合には、速やかに待機系のシステムが処理を引き継ぐ。

第２の方法は、サーバ単位での冗長化を行う方法である。この方法は、サーバ単位で同じ構成のシステムを用意し、ホットスタンバイ構成とする方法である。

なお、コンピュータ間の通信を行う通信システムにおいて、ネットワークシステムの各端末である特定のプロセスからのパケットのみを優先的に処理することができる通信システムが知られている。

また、遠隔操作装置において、新たなコードを登録したときにロックノブを作動して、新たなコード信号が登録されたことを表示できる遠隔操作装置が知られている。

更に、分散共有メモリ計算機システムにおいて、ネットワーク資源を有効利用するために一貫性保証制御と同期制御を少ないネットワークパケット数で実現し、分散共有メモリへのアクセス性能を向上させる分散共有メモリ計算機システムが知られている。
特開平４−１８０４２５号公報 特開２００１−２２７２１９号公報 特開平８−１０６４４０号公報

メッセージキューを用いてアプリケーション間の連携を行うサーバ等のシステムの場合、送信側と受信側のアプリケーションは、お互いの状態を認識する必要はない。しかし、本発明者の検討によれば、受信側のアプリケーションを冗長化する場合、以下の課題がある。

第１に、受信側のアプリケーションが異常終了した後、システムが時間あたりの処理量の回復まで時間を要する。異常終了したアプリケーションのプロセスの数だけ新たにプロセスを起動する場合に、プロセス起動時及び初期化処理により、システムが元のスループットになるまでに時間がかかるという問題がある。その結果、再起動時のＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）などが現在処理中のアプリケーションの性能に悪影響を与えることになるため、性能を重要視するシステム等で問題となる場合がある。

第２に、アプリケーションのプロセス単位でホットスタンバイ構成をとる方法の場合には、全く同じアプリケーションのプログラムを２つ以上用意する必要がある。しかし、ＰＵＬＬ型メッセージキュー、即ち、受信側のアプリケーションがメッセージを要求するようなメッセージ処理を使用したアプリケーションでは、待機プロセス側はメッセージキューからの受信を抑止する処理を実装する必要がある。

本発明は、プロセス起動時の他のプロセスへの性能に及ぼす影響を排除することができる冗長化されたアプリケーションの連携を行うアプリケーション間のメッセージキューイング方法を提供することを目的とする。

また、本発明は、プロセス起動時の他のプロセスへの性能に及ぼす影響を排除することができる冗長化されたアプリケーションの連携を行うアプリケーション間のメッセージキューイングを実行するプログラムを提供することを目的とする。

開示するメッセージキューイング方法は、メッセージを送信する送信アプリケーションと、多重化して構成されたメッセージを受信する複数の受信アプリケーションとの間のメッセージの送受信を処理するコンピュータが実行するメッセージキューイング方法である。このメッセージキューイング方法は、前記受信アプリケーションについての現用として設定可能なプロセス数の最大数である最大現用数と起動されている起動プロセスとを取得し、前記起動プロセスの各々について現用又は待機のいずれかの状態をプロセス制御テーブルに設定するプロセス制御ステップと、前記送信アプリケーションからのメッセージをキューイング処理するメッセージキューイングステップと、前記プロセス制御テーブルに現用が設定されたプロセスのみに対して、前記キューイングされているメッセージを取り出して送信するメッセージ受信制御ステップとを備える。

開示するメッセージキューイングプログラムは、コンピュータにおいて実行され、前述したメッセージキューイング方法を実現する。

開示するメッセージキューイング方法及びプログラムによれば、受信アプリケーションの起動されているプロセスのうち、現用に設定されたプロセスのみが送信アプリケーションからのメッセージを受信し、待機に設定されたプロセスに対する送信アプリケーションのメッセージ送信は行われないというメッセージ送信制御を実現する。

従って、受信アプリケーションの待機のプロセスにメッセージ受信を行わないための機能を設ける必要がないため、起動されている他のプロセスへ影響を及ぼすことなく、プロセス冗長化を簡単に実現することができる。即ち、予め冗長化された複数のプロセスが起動される。このため、初期化処理等による業務復帰までのタイムロスが少なく、速やかに業務再開を実現することができる。また、プロセス起動時の他のプロセスへの性能に及ぼす影響を排除することができる。更に、受信アプリケーションにおいて、冗長化の構成に対応させる処理を実行するためのプログラムの追加が不要になるので、アプリケーションの独立性を高めることができる。

図１は、本実施形態における情報処理装置の構成の一例を示す図である。

図１の情報処理装置は、メッセージ処理装置１と、複数のアプリケーション２とを備えるコンピュータシステムである。メッセージ処理装置１は、メッセージキュー部１０と、メッセージ受信制御部１１と、監視スレッド部１２とを備える。メッセージ受信制御部１１は、プロセス制御部１３を備える。アプリケーション２は、当該コンピュータ上で実行されるプログラムであり、実際には、当該コンピュータにおいて生成されたプロセス（又はスレッド）により実行される。従って、アプリケーション２をアプリケーション２のプロセスとも言う。送信側のアプリケーション２に符号Ａを付して表し、受信側のアプリケーション２に符号Ｂを付して表すこととする。

メッセージ処理装置１は、このコンピュータシステムにおいて、メッセージキューイング処理により、送信側のアプリケーション２Ａからのメッセージ１００を受信側のアプリケーション２Ｂに送信する。

なお、メッセージ処理装置１とアプリケーション２Ａ及び／又は２Ｂとを、異なるコンピュータに設けるようにしても良い。例えば、メッセージ処理装置１をサーバに設け、送信側のアプリケーション２Ａ及び受信側のアプリケーション２Ｂの一方又は双方をネットワークを介して前記サーバに接続された他のコンピュータ（クライアントマシーン）により実行するようにしても良い。

受信側のアプリケーション２Ｂは冗長化される。この冗長化のために、メッセージ処理装置１は、予め利用者から「利用者の設定」の入力を受け付ける。「利用者の設定」により、受信側のアプリケーション２Ｂの冗長構成が指定される。本発明実施例においては、「利用者の設定」において、受信側のアプリケーション２Ｂの数が“５”に設定され、かつ、現用系のアプリケーション２Ｂの多重数（並列して又は同時に存在する数、以下同じ）が“３多重”に設定されているものとする。従って、待機系のアプリケーション２Ｂの多重数は“２多重”となる。現用系のアプリケーション２Ｂの数の最大値が最大現用数（又は最大現用プロセス数）である。最大現用数とは、受信側のアプリケーション２Ｂを実行するプロセスであって、並列して又は同時に現用として設定可能なプロセスの数の最大値である。

メッセージ処理装置１は、「利用者の設定」に基づいて、アプリケーション２Ｂのプロセスの生成順（２Ｂ−１を１番目とし、２Ｂ−１〜２Ｂ−５の生成順とする）に、現用プロセスを３つ、待機プロセスを２つとして、メッセージ処理を行う。１番目に生成されたアプリケーション２Ｂをアプリケーション２Ｂ−１と表し、以下生成順にアプリケーション２Ｂ−１〜２Ｂ−５と表すものとする。なお、実際に生成されるのは、アプリケーション２Ｂを実行することになるプロセスである。メッセージ処理は、メッセージのキューイングにより送信側のアプリケーション２Ａと、受信側の複数のアプリケーション２Ｂの現用プロセス間のメッセージの送受信を行うものである。

メッセージキュー部１０は、送信側のアプリケーション２Ａから受信側のアプリケーション２Ｂに送られるメッセージ１００を受信し、一時的にメッセージ１００を保存する。

メッセージキュー部１０は、保存したメッセージ１００の宛先（通信パス等）をメッセージ受信制御部１１へ通知する。メッセージキュー部１０は、メッセージ受信制御部１１からメッセージ１００の送信要求がある場合に、保存したメッセージ１００を取り出し、メッセージ受信制御部１１に取り出したメッセージ１００を送信する。

なお、アプリケーション２Ｂ−１に送信されるメッセージ１００をＭ１と表し、アプリケーション２Ｂ−２に送信されるメッセージ１００をＭ２と表し、アプリケーション２Ｂ−３に送信されるメッセージ１００をＭ３と表すものとする。

メッセージ受信制御部１１は、メッセージキュー部１０から保存されたメッセージ１００の宛先（通信パス等）の通知を受ける。メッセージ受信制御部１１は、プロセス制御部１３が備えるプロセス制御表１１０に基づいて、メッセージ１００の宛先から保存されたメッセージ１００の取り出しを判断し、取り出したメッセージ１００は対応するアプリケーション２Ｂへ送信する。

具体的には、メッセージ受信制御部１１は、プロセス制御表１１０に基づいて、保存されたメッセージ１００の宛先から、現用プロセスのアプリケーションのみへのメッセージ１００（Ｍ１、Ｍ２、Ｍ３）を取り出し、取り出したメッセージ１００（Ｍ１、Ｍ２、Ｍ３）を現用プロセスであるアプリケーション２Ｂ−１、２Ｂ−２、２Ｂ−３それぞれへ送信する。一方、メッセージ受信制御部１１は、メッセージキュー部１０が保存するメッセージ１００の宛先が待機プロセスのアプリケーション２Ｂ−４、２Ｂ−５であれば、これらのアプリケーション２Ｂ−４、２Ｂ−５に対するメッセージ１００を取り出さず、送信を行わない。

監視スレッド部１２は、メッセージ受信制御部１１と受信側のアプリケーション２Ｂ間の通信状態等を所定の単位の監視スレッドで監視する。監視スレッド部１２は、監視スレッドに基づいて、受信側のアプリケーション２Ｂのプロセスの状態を監視し、受信側のアプリケーション２Ｂのプロセス状態の変化（プロセスの生成、異常終了等）をメッセージ受信制御部１１に通知する。これにより、メッセージ受信制御部１１は、アプリケーション２Ｂのプロセスの状態を監視することができる。

プロセス制御部１３は、メッセージの送信を判断するためのプロセス制御表１１０を備えて、複数のアプリケーション２Ｂの現用プロセス及び待機プロセスを管理する。

プロセス制御表１１０の構成及び詳細な説明については、後述する図５の説明にて行う。また、図１に示す実施形態の動作説明については、図２乃至図４の動作説明にて行う。

図１に示す本発明の実施態様によれば、アプリケーション２Ｂ側では、各プロセスが現用プロセスであるか待機プロセスであるかを区別して認識する必要はない。即ち、メッセージ処理装置１が、現用プロセスと待機プロセスであるかを管理し、メッセージを送信するか否かを判断する。このため、受信側のアプリケーション２Ｂは、メッセージの受信を待つだけである。従って、アプリケーション２Ｂ側のプロセスで現用と待機との場合を区別してプロセスを作りこむ必要がない。このため、アプリケーション２Ｂの独立性を確保することができる。

図２は、アプリケーション２Ｂ−１〜２Ｂ−５がメッセージ受信制御部１１に接続した場合の処理（第１の処理）を示す。

利用者は、予めメッセージ受信側の同一アプリケーション２Ｂのプロセスを必要な多重数分起動する。図２において、例えば、予め利用者が受信側のアプリケーション２Ｂの数を“５”と設定し、かつ、現用系のアプリケーション２Ｂの多重数を“３多重”として設定する。設定に基づいてアプリケーション２Ｂ−１〜２Ｂ−５が多重起動される。

アプリケーション２Ｂは、プロセスの生成をメッセージ受信制御部１１へ通知する（処理Ｔ１）。メッセージ受信制御部１１は、アプリケーション２Ｂの生成されたプロセスに対する監視スレッドを生成し（処理Ｔ２）、監視スレッド部１２が生成された監視スレッドによりアプリケーション２Ｂのプロセスの状態を監視する（処理Ｔ３）。

プロセス制御部１３は、アプリケーション２Ｂのプロセス生成を受けて、プロセスの生成順にアプリケーション２Ｂ−１〜２Ｂ−５のプロセスを管理するデータをプロセス制御表１１０へ保存する。

メッセージ受信制御部１１は、メッセージキュー部１０へ現用プロセスであるアプリケーション２Ｂ−１〜２Ｂ−３のメッセージ１００（Ｍ１、Ｍ２、Ｍ３）の受信要求を行う（処理Ｔ４）。

メッセージキュー部１０は、送信側のアプリケーション２Ａに対して、メッセージ１００（Ｍ１、Ｍ２、Ｍ３）が受信許可であることを通知する（処理Ｔ５）。

メッセージ１００の受信許可の通知を受けた送信側のアプリケーション２Ａは、メッセージＭ１、Ｍ２、Ｍ３をメッセージ処理装置１に送信する（処理Ｔ６）。メッセージ処理装置１のメッセージキュー部１０は、メッセージＭ１〜Ｍ３を受信し、受信したメッセージＭ１〜Ｍ３のキューイング処理（待ち行列の処理）を行う。

メッセージキュー部１０は、メッセージＭ１を受信した後、メッセージＭ１を保存していることを、メッセージ受信制御部１１へ通知する。通知を受けたメッセージ受信制御部１１が、メッセージＭ１をメッセージキュー部１０から取り出す（処理Ｔ７）。

メッセージ受信制御部１１は、取り出したメッセージＭ１を現用プロセスのアプリケーション２Ｂ−１へ送信する（処理Ｔ８）。メッセージＭ２及びＭ３についても同様な処理を行う（処理Ｔ９〜Ｔ１０及び処理Ｔ１１〜Ｔ１２）。

一方、メッセージ受信制御部１１は、待機プロセスのアプリケーション２Ｂ−４及び２Ｂ−５のメッセージは取り出さない（処理Ｔ１３、処理Ｔ１４）。

メッセージ受信制御部１１は、アプリケーション２Ｂ−４及び２Ｂ−５へメッセージ１００を送信しないため、アプリケーション２Ｂ−４及び２Ｂ−５側にとっては、メッセージ受信待ちの状態を継続している。アプリケーション２Ｂ−４及び２Ｂ−５側では、メッセージ受信待ちであるだけであり、プロセスが待機であるという区別はない。

図３は、受信側の現用系のアプリケーション２Ｂの現用プロセスがダウンした場合に、アプリケーション２Ｂの待機プロセスが現用プロセスに昇格する場合の処理（第２の処理）を示す。

具体的には、図３では、アプリケーション２Ｂ−１〜２Ｂ−３を受信側の現用系アプリケーションとして３多重とした状態（図２に示した第１の処理の状態）において、現用プロセスのうち１つがダウンした場合に、待機プロセスを現用プロセスに昇格させる場合の処理を示す。

現用プロセスであるアプリケーション２Ｂ−１のプロセスが、異常終了等によりダウンした場合に、メッセージ受信制御部１１は、アプリケーション２Ｂの生成されたプロセスに対する監視スレッドを確認する（処理Ｔ２１）。メッセージ受信制御部１１は、監視スレッド部１２に問い合せを行う（処理Ｔ２２）。

監視スレッド部１２がアプリケーション２Ｂのプロセス状態を監視し（処理Ｔ２３）、アプリケーション２Ｂ−１のプロセスがダウンしている状態と判断し、メッセージ受信制御部１１にその状態を通知する。

通知を受けたメッセージ受信制御部１１のプロセス制御部１３は、プロセス制御表１１０からアプリケーション２Ｂ−１のプロセスに対応するデータを削除する。

メッセージ受信制御部１１は、現用プロセス数が“２”になったことを認識し、現用プロセス数を“３”に保つため、プロセス制御表１１０上において、アプリケーション２Ｂ−４のプロセスを待機プロセスから現用プロセスに昇格させるデータの更新を行う。

更新されたプロセス制御表１１０により、メッセージ受信制御部１１は、メッセージキュー部１０へ現用プロセスとなったアプリケーション２Ｂ−４のメッセージ１００の受信許可の通知を行う（処理Ｔ２４）。

メッセージ１００の受信許可の通知を受けた送信側のアプリケーション２Ａは、メッセージＭ２、Ｍ３、Ｍ４をメッセージ処理装置１に送信する（処理Ｔ２５）。

メッセージキュー部１０は、メッセージＭ２〜Ｍ４を受信し、メッセージキュー部１０が受信したメッセージＭ２〜Ｍ４のキューイング処理（待ち行列の処理）を行う。メッセージキュー部１０は、メッセージＭ２を受信した後、メッセージＭ２を保存していることを、メッセージ受信制御部１１へ通知する。

通知を受けたメッセージ受信制御部１１が、メッセージＭ２をメッセージキュー部１０から取り出す（処理Ｔ２６）。メッセージ受信制御部１１は、取り出したメッセージＭ２を現用プロセスのアプリケーション２Ｂ−２へ送信する（処理Ｔ２７）。メッセージＭ３及びＭ４についても同様な処理を行う（処理Ｔ２８〜Ｔ２９及び処理Ｔ３０〜Ｔ３１）。

メッセージ受信制御部１１は、待機プロセスのアプリケーション２Ｂ−５のメッセージは取り出さない（処理Ｔ３２）。また、メッセージ受信制御部１１は、プロセスダウンと判断したアプリケーション２Ｂ−１へメッセージ１００の受信処理を行わない。

以上のように、現用プロセスのアプリケーション２Ｂ−１が異常終了等によりプロセスダウンした場合においても、メッセージ処理装置１内で、アプリケーション２Ｂ−４の待機プロセスから現用プロセスにプロセスを昇格させることができる。

これにより、メッセージ処理装置１は、速やかにメッセージ受信待ち状態のアプリケーション２Ｂ−４の昇格した現用プロセスへメッセージＭ４を送信することができる。

図４は、受信側の現用系のアプリケーション２Ｂの現用プロセスがダウンし、待機プロセスが現用プロセスに昇格した状態（図３に示した第２の処理の状態）の後、メッセージ受信制御部１１がアプリケーション２Ｂの待機プロセスとして補充する場合の処理（第３の処理）を示す。

現用プロセスであるアプリケーション２Ｂ−１のプロセスが、異常終了等によりダウンした後、利用者が新たにアプリケーション２Ｂ−６のプロセスを起動する（追加する）。プロセスの起動後、アプリケーション２Ｂ−６は、プロセスの生成をメッセージ受信制御部１１へ通知する（処理Ｔ４１）。従って、メッセージ受信制御部１１は、アプリケーション２Ｂによる新たなプロセスの追加を受け付ける。

新たなプロセス起動が通知されると、メッセージ受信制御部１１は、アプリケーション２Ｂ−６のプロセスに対する監視スレッドを生成し（処理Ｔ４２）、監視スレッド部１２が生成された監視スレッドによりアプリケーション２Ｂ−６のプロセスの状態を監視する（処理Ｔ４３）。

この際、通知を受けたプロセス制御部１３は、プロセス制御表１１０へアプリケーション２Ｂ−６のプロセスに対応するデータを追加する。更に、プロセス制御部１３は、プロセス制御表１１０上で待機プロセス数が“１”に減じたことにより、アプリケーション２Ｂ−６のプロセスを待機プロセスとして補充するため、プロセス制御表１１０の更新を行う。

メッセージ受信制御部１１は、更新されたプロセス制御表１１０に基づいて、メッセージキュー部１０へ現用プロセスであるアプリケーション２Ｂ−２〜２Ｂ−４のメッセージ１００の送信許可の通知を行う（処理Ｔ４４）。

メッセージ１００の受信許可の通知を受けた送信側のアプリケーション２Ａは、メッセージＭ２、Ｍ３、Ｍ４をメッセージ処理装置１に送信する（処理Ｔ４５）。

メッセージキュー部１０は、メッセージＭ２〜Ｍ４を受信し、受信したメッセージＭ２〜Ｍ４のキューイング処理（待ち行列の処理）を行う。メッセージキュー部１０は、メッセージＭ２を受信した後、メッセージＭ２を保存していることを、メッセージ受信制御部１１へ通知する。通知を受けたメッセージ受信制御部１１が、メッセージＭ２をメッセージキュー部１０から取り出す（処理Ｔ４６）。

メッセージ受信制御部１１は、取り出したメッセージＭ２を現用プロセスのアプリケーション２Ｂ−２へ送信する（処理Ｔ４７）。メッセージＭ３及びＭ４についても同様な処理を行う（処理Ｔ４８〜Ｔ４９及びＴ５０〜Ｔ５１）。メッセージ受信制御部１１は、待機プロセスのアプリケーション２Ｂ−５及び２Ｂ−６のメッセージ１００は取り出さない（処理Ｔ５２、Ｔ５３）。

以上のように、メッセージ処理装置１は、利用者が後から起動したアプリケーション２Ｂのプロセスであっても、起動したアプリケーション２Ｂをメッセージ処理装置１に接続した後、現用プロセス又は待機プロセスとして、プロセス制御表１１０に補充することができる。本発明の実施態様によれば、メッセージ処理装置１内でアプリケーション２Ｂの現用プロセス及び待機プロセスを管理する。このため、速やかに現用プロセス又は待機プロセスとして補充し、冗長化されたアプリケーション２Ｂへメッセージ処理の準備を速やかに行うことができる。

なお、利用者がアプリケーション２Ｂを補充するタイミングは、業務処理の運用に影響のないタイミングで、かつ、後から起動して補充するタイミングであっても良い。

図４の例では、現用のアプリケーション２Ｂの数が設定された数（＝３）に達しているため、後から補充されたアプリケーション２Ｂは待機のアプリケーション２Ｂとなる。

図５は、本実施形態におけるプロセス制御表１１０のデータ構造を説明する図である。

図５（Ａ）は、メッセージ受信制御部１１がメッセージ１００の受信先を管理するためのプロセス制御表１１０のデータ構造を示す図である。プロセス制御表１１０は、プロセス識別子１１１毎に、少なくとも、それに対応する通信パス１１２、現用フラグ１１３、次のデータへのポインタであるｎｅｘｔポインタ１１４を含むデータで構成されている。

プロセス識別子１１１は、アプリケーション２Ｂのプロセスを実行する順位を識別するための識別子である。通信パス１１２は、ソケット（ｓｏｃｋｅｔ）の指定である（宛先
ＩＰアドレスとポート番号の組等を指定）。

現用フラグ１１３は、対応するプロセスが現用である場合には“ＯＮ”のデータが設定され、プロセスが待機の場合には“ＯＦＦ”のデータが設定される。ｎｅｘｔポインタ１１４には、自プロセスの次のプロセス先（プロセスの生成順）を示すポインタが設定される。

プロセス制御部１３は、プロセス識別子１１１毎に複数のデータを含むデータ構造のプロセス生成順の連結したデータ連結リストをプロセス制御表１１０として管理する。プロセス制御部１３は、プロセス制御表１１０にデータを追加又は削除し、図５（Ｂ）に示すデータ連結リストを連結し直す。

図５（Ｂ）は、プロセス制御表１１０のデータ連結リストの例を示す図である。図５（Ｂ）においては、図２に示した第１の処理におけるプロセス制御表１１０のデータ連結リストを示す。

プロセス制御部１３は、メッセージ受信制御部１１からのプロセスの生成の通知を得て、利用者からの設定に基づいて（例えば、現用プロセス＝３で、待機プロセス＝２の場合）、プロセスの生成順にプロセス制御表１１０に各プロセスのデータ（図５（Ｂ）中の１１０−１〜１１０−５で示す）を、順次追加する。

例えば、プロセス制御表１１０のプロセス識別子１１１が“１”に対応する現用プロセスのデータ１１０−１は、通信パス１１２が“ｓｏｃｋｅｔ１”（例えば、特定の宛先のソケット）で、現用フラグ１１３が“ＯＮ”（現用プロセス）であることを示す。同様に、データ１１０−２及び１１０−３は、プロセス識別子１１１が“２”及び“３”に対応する現用プロセスである。

また、待機プロセスのデータは、現用フラグ１１３が“ＯＦＦ”であり、図５（Ｂ）の例では、プロセス識別子１１１が“４”及び“５”に対応するプロセスである（データ１１０―４及び１１０−５）。

メッセージ受信制御部１１は、プロセスの生成順を、プロセス制御表１１０のｎｅｘｔポインタ１１４により判断する。例えば、プロセスの生成順は、ｎｅｘｔポインタ１１４の先頭がデータ１１０−１であり、次はデータ１１０−２、・・・データ１１０−５とｎｅｘｔポインタ１１４によりリンクされている。

なお、プロセス識別子５のｎｅｘｔポインタ１１４のリンク先がない場合に“ＮＵＬＬ”が設定されるため、最後の生成順のプロセスのデータ１１０−５のｎｅｘｔポインタ１１４は、ＮＵＬＬ（ヌルデータ）となる。以上のように、プロセス制御部１３は、データ１１０−１〜１１０―５を生成順に連結する。

図６は、本実施形態におけるプロセス制御表１１０のデータ連結の変更を説明するための図である。図６（Ａ）は、メッセージ受信制御部１１のプロセス昇格の制御におけるデータ連結の変更を説明するための図、及び、図６（Ｂ）は、プロセス補充の制御におけるデータ連結の変更を説明するための図である。

図６（Ａ）は、図５（Ｂ）に示す現用プロセス及び待機プロセス数である状態から、１つのプロセスがダウン（異常終了）した場合に、図３に示した第２の処理に対応したプロセス制御表１１０のデータ連結の変更の例である。

まず、メッセージＭ１の送信対象であるプロセス識別子１１１が“１”に対応する現用プロセスが、正常終了する前にダウンした場合に、監視スレッド部１２は、現用プロセス（図３の２Ｂ−１）のダウンを認識し、ダウンしたプロセスの情報をメッセージ受信制御部１１に通知する。

すると、プロセス制御部１３は、メッセージ受信制御部１１を介して監視スレッド部１２から通知された情報に基づいて、プロセス制御表１１０からダウンした現用プロセスに対応するデータ１１０−１を削除する。更に、プロセス制御部１３は、プロセスの生成順をデータ１１０−２のｎｅｘｔポインタ１１４の先頭にして、データ連結リスト間を新たに繋ぎ直す。

また、プロセス制御部１３は、現用プロセスの数が“３”から“２”に減じたことを認識し、プロセス制御表１１０のｎｅｘｔポインタ１１４に従い、プロセス識別子１１１が“４”に対応する待機プロセス（図３の２Ｂ−４）の現用フラグ１１３を“ＯＦＦ”から“ＯＮ”に更新する（以下では、この処理を「現用プロセスへ昇格」ともいう）。

以上の処理の結果、メッセージ受信制御部１１は、プロセス識別子１１１が“４”であるプロセスを現用プロセスと判断することができる。

以上のように、プロセス制御部１３は、アプリケーション２Ｂの現用プロセスが異常終了又は正常終了した場合に、その終了したプロセスをプロセス制御表１１０から削除する。プロセス制御部１３は、プロセス制御表１１０からプロセスのデータ１１０−１を削除した後、データ連結リスト間の連結を更新する。

これにより、メッセージ受信制御部１１は、待機プロセスとしてメッセージ受信待ちであるアプリケーション２Ｂのプロセスを現用プロセスとして昇格させたことを判断することができる。

本発明の実施態様によれば、メッセージ処理装置１を備えることにより、アプリケーション２Ｂのプロセスがダウンした場合でも、短い時間でアプリケーション２Ｂに対するメッセージ受信の処理を続行することができる。

また、メッセージ処理装置１内でのみ現用プロセスと待機プロセスであるかを管理し、メッセージを送信するか否かを判断するため、受信側のアプリケーション２Ｂは、メッセージ１００の受信を待つのみである。従って、アプリケーション２Ｂ側の現用プロセスと待機プロセスを区別するアプリケーションの作りこみが不要となるため、アプリケーション２Ｂの独立性を確保できる。

図６（Ｂ）は、図６（Ａ）の現用プロセス及び待機プロセス数の状態から、１つのプロセスが補充された場合のデータ連結の変更例を説明するための図である。図６（Ｂ）は、図４に示した第３の処理に対応したプロセス制御表１１０である。

まず、プロセス制御部１３は、図６（Ａ）で説明したように起動したプロセスの数が“４”に減じた後に、利用者が後から起動したアプリケーション２Ｂ−６（図４に示す）のプロセスについて、以下のようにプロセス制御表１１０にデータ１１０−６を追加する。（以下では、この処理を「プロセスの補充」ともいう）。なお、ここで、利用者が設定したプロセス起動の多重数は“５”である。

メッセージ受信制御部１１はプロセス制御表１１０から待機プロセスの数が“２”から“１”に減じたことを判断する。メッセージ受信制御部１１は、監視スレッド部１２から通知された内容をプロセス制御部１３に通知する。プロセス制御部１３はこの通知に基づいて、プロセス制御表１１０に後から起動されたアプリケーション２Ｂ−６のプロセスに対応するデータ１１０−６を追加する。

そして、プロセス制御部１３は、プロセス制御表１１０にデータ１１０−６を追加した後、プロセスの生成順をもとにデータ１１０−５のｎｅｘｔポインタ１１４を“ＮＵＬＬ”からデータ１１０−６のポインタの設定へ更新する。

プロセス制御部１３は、プロセス制御表１１０の更新後にデータ連結リスト間を新たに連結し直す。この場合、プロセス制御部１３は、生成順の最後のデータ１１０−６のｎｅｘｔポインタ１１４を“ＮＵＬＬ”に設定する。

以上の結果、メッセージ受信制御部１１は、以降の処理で、アプリケーション２Ｂ−６のプロセスをプロセス制御表１１０に基づいて待機プロセスと判断することができる。

これにより、メッセージ受信制御部１１は、プロセス制御表１１０に基づいて、現用プロセスのアプリケーション２Ｂ（２Ｂ−２〜２Ｂ−４）に対してメッセージ１００を送信し、待機プロセスのアプリケーション２Ｂ（２Ｂ−５及び２Ｂ−６）に対してメッセージ１００を送信しないことを判断することができる。

また、メッセージ処理装置１は、アプリケーション２Ｂのプロセスの数が設定された値より減った場合に、別途起動されたアプリケーション２Ｂのプロセスを現用プロセス又は待機のプロセスとし、プロセス制御表１１０を更新することにより、プロセスの補充に速やかに対応することができる。

以上説明したように、本発明の実施形態によれば、アプリケーション２Ｂとして予め冗長なプロセスを起動しているため、初期化処理などによる業務復帰までのタイムロスがなく、アプリケーション異常終了時のシステム処理量を維持し、速やかに業務再開を実現することができる。

更に、本実施形態によれば、プロセス起動時の他のプロセスへの性能に及ぼす影響を排除することができる。また、本実施形態によれば、アプリケーション側での冗長化のための作りこみが不要になるため、システムの独立性を高めることができる。

図７乃至図１１を用いて、本実施形態における図１の構成を備えるメッセージ処理装置１が実行する処理フローの説明を行う。

図７は、本実施形態における、受信側のアプリケーション２Ｂの処理フローである。

アプリケーション２Ｂは、メッセージ処理装置１への通信資源を獲得した後は、メッセージ１００の要求、メッセージ１００に対する業務処理を繰り返すという、簡易な処理フローとなる。ここで、「通信資源の獲得」とは、メッセージ処理装置１とアプリケーション２Ｂ間の通信が可能で、アプリケーション２Ｂがメッセージ１００を受信可能な状態の成立をいう。図７において、「メッセージ処理装置への通信資源獲得」、「メッセージ処理装置へメッセージ受信依頼」、「メッセージ処理装置への通信資源解放」の処理は、メッセージ処理装置１の関数であり、アプリケーション２Ｂから内部処理は隠蔽される。

利用者によりアプリケーション２Ｂが起動されると、アプリケーション２Ｂの処理が開始される。起動後、アプリケーション２Ｂは、予め定められた初期化処理を行い（ステップＳ１）、メッセージ処理装置１に対して通信資源の獲得を要求し（ステップＳ２）、メッセージ処理装置１に対してメッセージ１００の受信依頼（メッセージの要求）を行う（ステップＳ３）。

アプリケーション２Ｂは、要求したメッセージ１００を受信すると、メッセージ１００に対する業務処理を行い（ステップＳ４）、処理を終了するか否かを判断する（ステップＳ５）。処理を終了しない場合、アプリケーション２Ｂは、ステップＳ３以下を繰り返すことにより、引続き、業務処理を行う。

ステップＳ５において処理を終了する場合、アプリケーション２Ｂは、処理を終了する前に、メッセージ処理装置１へ通信資源の開放の通知を行う（ステップＳ６）。この後、アプリケーション２Ｂは、アプリケーションの終了処理を行う（ステップＳ７）。

図８（Ａ）は、本実施形態におけるメッセージ処理装置１の通信資源の獲得処理の処理フローである。

メッセージ処理装置１のメッセージ受信制御部１１は、アプリケーション２Ｂから通信資源の獲得要求を受けると、以下の処理を開始する。メッセージ受信制御部１１は、アプリケーション２Ｂから通信資源の獲得要求の通知を受信する（ステップＳ１０）。メッセージ受信制御部１１は、通信資源の獲得要求の通知を受信した後、通信資源の獲得を行う（ステップＳ１１）。次に、メッセージ受信制御部１１は、アプリケーション２Ｂとメッセージ処理装置１の間の通信状態を監視するための監視スレッドを作成する（ステップＳ１２）。

なお、生成された監視スレッドは、後述の図９で説明する監視スレッド部１２の処理において、監視対象となる。

図８（Ｂ）は、本実施形態におけるメッセージ処理装置１の通信資源の解放処理の処理フローである。

メッセージ処理装置１のメッセージ受信制御部１１は、アプリケーション２Ｂから通信資源の解放要求の通知を受信する（ステップＳ１３）。その通知を受信後、メッセージ受信制御部１１は、アプリケーション２Ｂの対象となるプロセスとの通信資源を開放する（ステップＳ１４）。以上の処理で、メッセージ処理装置１の通信資源の解放処理は終了する。

図９は、本実施形態におけるメッセージ処理装置１に備えられた監視スレッド部１２の監視処理フローを示す図である。

メッセージ受信制御部１１が監視スレッドを生成すると、監視スレッド部１２は、以下の監視処理を開始する。監視スレッド部１２は、メッセージ受信制御部１１とアプリケーション２Ｂ間の通信状態や監視対象が有るか無いか等の状態（通信資源状態）を監視する（ステップＳ１５）。

監視スレッド部１２は、その監視した結果に基づいて、通信資源があるか否かを判断する（ステップＳ１６）。“通信資源がある”と判断した場合、監視スレッド部１２は、ステップＳ１５以下の処理を繰り返す。

ステップＳ１６において“通信資源がない”と判断した場合、監視スレッド部１２は、監視スレッドの監視内容に基づいて、アプリケーション２Ｂのプロセスが終了又は通信不能による停止状態等と判断して、メッセージ受信制御部１１へプロセス終了の通知を送信する（ステップＳ１７）。この通知は、監視スレッド部１２からメッセージ受信制御部１１へ非同期に送られる通知である。

図１０は、本実施形態におけるメッセージ処理装置１のメッセージ受信依頼時の受信制御の処理フローを示す図である。

メッセージ処理装置１は、アプリケーション２Ｂからのメッセージの受信依頼の通知を受けてから以下の処理を開始する。メッセージ処理装置１のメッセージ受信制御部１１は、アプリケーション２Ｂからのメッセージ１００の受信依頼の通知を受信した場合、通知を送信したアプリケーション２Ｂのプロセスが現用であるか否かを判断する（ステップＳ２０）。このために、メッセージ受信制御部１１は、プロセス制御表１１０を参照し、当該アプリケーション２Ｂのプロセスが現用プロセス又は待機プロセスのいずれであるかを調べる。

当該アプリケーション２Ｂのプロセスが現用プロセスでない（待機プロセスである）場合、アプリケーション２Ｂの待機プロセスは、メッセージ受信制御部１１に対し、メッセージ１００の受信を実行するための実行許可申請を通知し（ステップＳ２１）、メッセージ受信制御部１１からの許可を受信するまで待機する（ステップＳ２２）。なお、ステップＳ２１及びＳ２２の処理は、非同期の通信により実行される。

メッセージ受信制御部１１は、即ち、プロセス制御部１３は、プロセス制御表１１０上の対応する待機プロセスの現用フラグのデータを現用に設定する（ステップＳ２３）。これにより、メッセージ受信制御部１１は、プロセスの生成や終了等の状態により現用プロセス数が減じた場合に、待機プロセスを現用プロセスに昇格させる。

一方、ステップＳ２０において、当該アプリケーション２Ｂのプロセスが現用プロセスである（待機プロセスでない）場合、メッセージ受信制御部１１は、メッセージキュー部１０に対し、現用プロセスのアプリケーション２Ｂに関するメッセージ１００の受信依頼を行う（ステップＳ２４）。

メッセージキュー部１０が現用プロセスに対するメッセージ１００を受信した場合、メッセージ受信制御部１１は、メッセージキュー部１０から受信したメッセージ１００を取り出し、取り出したメッセージ１００をアプリケーション２Ｂの現用プロセスへ送信する（ステップＳ２５）。

以上のように、メッセージ処理装置１は、現用プロセスとして管理するアプリケーション２Ｂのプロセスへメッセージ受信の実行許可を通知し、待機プロセスとして管理するアプリケーション２Ｂのプロセスへメッセージ受信の実行許可の通知を送信しない。これにより、受信側のアプリケーション２Ｂは、メッセージ処理装置１からメッセージ受信の実行許可を得られた場合には、メッセージ処理装置１からメッセージ１００を受信する。一方、受信側のアプリケーション２Ｂは、メッセージ処理装置１からメッセージ受信の実行許可を得られない間は、メッセージ１００の受信待ちの状態となる。

図１１は、本実施形態におけるメッセージ受信制御部１１の現用プロセス及び待機プロセスの管理を行う処理の処理フローである。

メッセージ受信制御部１１は、アプリケーション２Ｂとの通信待ち状態から、現用プロセス及び待機プロセスの管理を以下の処理により開始する。メッセージ受信制御部１１は、利用者が設定した最大現用プロセス数を取得し（ステップＳ３０）、アプリケーション２Ｂからの問い合せ等の通知を待つ（ステップＳ３１）。

メッセージ受信制御部１１は、アプリケーション２Ｂから問い合せ等の通知を受信した場合、その通知内容において通信種別が実行許可申請であるか否かを判断する（ステップＳ３２）。通信種別が実行許可申請である場合、メッセージ受信制御部１１のプロセス制御部１３は、プロセス制御表１１０に通知元のプロセス識別子１１１等のデータを追加する（ステップＳ３３）。

プロセス制御部１３は、更に、現用プロセス数が最大現用プロセス数（利用者の設定による）より小さいか否かを判断する（ステップＳ３４）。

現用プロセス数が最大現用プロセス数より小さくない（大きい）場合、プロセス制御部１３は、当該プロセスは待機プロセスであるとみなし、“実行許可”の通知を返信しないで、ステップＳ３０の処理に戻る。これにより、待機プロセスとみなされた通信元のアプリケーション２Ｂは応答待ち状態となる。

ステップＳ３４において現用プロセス数が最大現用プロセス数より小さい場合、プロセス制御部１３は、追加したプロセス識別子を備えるプロセスを現用プロセスに追加した上で、“現用プロセス数＋１”として、この演算結果をプロセス制御部１３が備えるメモリへ記憶する（ステップＳ３５）。これに加えて、プロセス制御部１３は、プロセス制御表１１０において追加したプロセスのデータの現用フラグ１１３を“ＯＮ”に設定する（ステップＳ３６）。この後、メッセージ受信制御部１１は、プロセス制御表１１０に基づいて、現用フラグ１１３を“ＯＮ”と設定したアプリケーション２Ｂの現用プロセスへ、“実行許可”の通知を返信する（ステップＳ３７）。

ステップＳ３２においてアプリケーション２Ｂの通知内容において通信種別が実行許可申請でない場合、メッセージ受信制御部１１は、更に、通信種別が通信途絶検出（プロセスダウン）であるか否かを判断する（ステップＳ３８）。通信種別が通信途絶検出でない場合、メッセージ受信制御部１１は、ステップＳ３０以下の処理を繰り返す。

通信種別が通信途絶検出である場合、プロセス制御部１３は、プロセス制御表１１０から対応するプロセスのデータを削除する（ステップＳ３９）。この後、プロセス制御部１３は、削除したデータのプロセスが現用プロセスであるか否かを判断する（ステップＳ４０）。当該プロセスが現用プロセスでない場合、メッセージ受信制御部１１は、ステップＳ３０以下の処理を繰り返す。

当該プロセスが現用プロセスである場合、メッセージ受信制御部１１は、プロセス制御部１３が備えるメモリへ記憶した現用プロセス数から１を減じて、この演算結果の現用プロセス数を当該メモリに記憶する（ステップＳ４１）。この後、プロセス制御部１３は、プロセス制御表１１０からプロセスの生成順に従い待機プロセスを選択し、その待機プロセスを現用プロセスの候補として選択し（ステップＳ４２）、ステップＳ３４以下の処理を繰り返す。

本実施形態における情報処理装置の構成を示す図である。 本実施形態における第１の処理を示す図である。 本実施形態における第２の処理を示す図である。 本実施形態における第３の処理を示す図である。 本実施形態におけるプロセス制御表のデータ構造を示す図である。 本実施形態におけるプロセス制御表のデータ連結の変更を示す図である。 本実施形態における受信側のアプリケーションの処理フローである。 本実施形態における通信資源の獲得処理及び解放処理の処理フローである。 本実施形態における監視処理の処理フローである。 本実施形態におけるメッセージ受信依頼時の受信制御の処理フローである。 本実施形態における現用及び待機プロセス管理処理の処理フローである。

符号の説明

１ メッセージ処理装置
２ アプリケーション
１０ メッセージキュー部
１１ メッセージ受信制御部
１２ 監視スレッド部
１３ プロセス制御部
１００ メッセージ
１１０ プロセス制御表

Claims (5)

1. メッセージを送信する送信アプリケーションと、多重化して構成されたメッセージを受信する複数の受信アプリケーションとの間のメッセージの送受信を処理する、コンピュータが実行するメッセージキューイング方法であって、
   前記受信アプリケーションについての現用として設定可能なプロセス数の最大数である最大現用数と起動されている起動プロセスとを取得し、前記起動プロセスの各々について現用又は待機のいずれかの状態をプロセス制御テーブルに設定するプロセス制御ステップと、
   前記送信アプリケーションからのメッセージをキューイング処理するメッセージキューイングステップと、
   前記プロセス制御テーブルに設定された全てのプロセスと通信可能な状態を保持し、前記現用が設定されたプロセスのみに対して前記キューイングされているメッセージを取り出して送信するメッセージ受信制御ステップとを備える
   ことを特徴とするメッセージキューイング方法。
2. 前記現用が設定されたプロセスの通信状態を監視して通信障害を検出する通信管理ステップを備えると共に、
   前記プロセス制御ステップにおいて、前記現用が設定されたプロセスの通信障害が検出された場合に、前記プロセス制御テーブルに待機が設定された少なくとも１つのプロセスの設定を現用に変更する処理ステップを備える
   ことを特徴とする請求項１記載のメッセージキューイング方法。
3. 前記プロセス制御ステップにおいて、前記受信アプリケーションのプロセスの追加を受け付け、前記プロセス制御テーブルに該受け付けたプロセスを追加し、前記プロセス制御テーブルに現用が設定されたプロセス数が前記最大現用数以上である場合に、該追加されたプロセスに待機を設定する処理ステップを備える
   ことを特徴とする請求項１又は請求項２に記載のメッセージキューイング方法。
4. 前記プロセス制御ステップにおいて、前記受信アプリケーションのプロセスの追加を受け付け、前記プロセス制御テーブルに該受け付けたプロセスを追加し、前記プロセス制御テーブルに現用が設定されたプロセス数が前記最大現用数に達しない場合に、前記プロセス制御テーブルに待機が設定されたプロセス又は該追加されたプロセスのいずれかのプロセスに現用を設定する処理ステップを備える
   ことを特徴とする請求項１又は請求項２に記載のメッセージキューイング方法。
5. メッセージを送信する送信アプリケーションと、多重化して構成されたメッセージを受信する複数の受信アプリケーションとの間のメッセージの送受信を処理する、メッセージキューイングプログラムであって、
   前記受信アプリケーションについての現用として設定可能なプロセス数の最大数である最大現用数と起動されている起動プロセスとを取得し、前記起動プロセスの各々について現用又は待機のいずれかの状態をプロセス制御テーブルに設定するプロセス制御ステップと、
   前記送信アプリケーションからのメッセージをキューイング処理するメッセージキューイングステップと、
   前記プロセス制御テーブルに設定された全てのプロセスと通信可能な状態を保持し、前記現用が設定されたプロセスのみに対して前記キューイングされているメッセージを取り出して送信するメッセージ受信制御ステップとを、コンピュータに実行させる
   ことを特徴とするメッセージキューイングプログラム。

Images