(57)【要約】【課題】個々のキューに対しキューイングされている要求イベントの数あるいは保留限界時間に依存することなく、プログラムバグ等により動作が停止し、要求イベントをデキューできなくなり、要求イベントを処理することができなくなってしまう事象の発生を抑止する。【解決手段】キュー監視装置１００は、要求イベントの送受信を行う入出力装置（外部装置１０、２０、３０）と接続され、記憶装置１０２と、演算処理装置１０１とを備え、前記要求イベントを入出力装置から取得し、記憶装置の所定の領域に記憶する、少なくとも１個のキューを保持する複数の機能処理部（イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０）と、機能処理部が保持するキューの動作停止を所定の周期で監視するキュー監視部１４０と、を備える。【選択図】図２
2010003212.tif 000002
【特許請求の範囲】
【請求項１】
要求イベントの送受信を行う入出力装置と接続され、記憶装置と、演算処理装置とを備え、前記記憶装置の所定の領域に記憶されるキューの動作停止を監視するキュー監視装置であって、
前記演算処理装置において、前記入出力装置から要求イベントを取得し、前記記憶装置の所定の領域に記憶する、少なくとも１個のキューを保持する複数の機能処理部と、
前記演算処理装置において、前記機能処理部が保持するキューの動作停止を所定の周期で監視するキュー監視部と、
を備えたことを特徴とするキュー監視装置。
【請求項２】
前記キュー監視部は、
前記機能処理部が、前記キューに要求イベントを順番に格納するエンキュー処理時に、もしくは前記機能処理部が、前記キューから前記要求イベントを順番に取得するデキュー処理時に、前記のキューに設定され、前記記憶装置に記憶されるキュー監視情報に基づき、前記キューの動作停止を監視することを特徴とする請求項１に記載のキュー監視装置。
【請求項３】
前記キュー監視情報は、
前記キューに前記要求イベントがエンキューされたキューイングイベント数と、前記要求イベントが最後にデキューされたデキュー実行時刻と、１件の要求イベントを処理するのに必要十分な時間を示すデキュー未実行時間異常閾値と、前記デキュー未実行時間異常閾値とデキュー実行時刻から現在時刻までの時間とを比較することによりデキューが実行されない異常な状態と判定されたキュー停止判定回数と、を含むことを特徴とする請求項２に記載のキュー監視装置。
【請求項４】
前記キュー監視部は、
前記エンキュー処理の都度、該当キューのキュー監視情報における前記キューイングイベント数に１を加算することを特徴とする請求項３に記載のキュー監視装置。
【請求項５】
前記キュー監視部は、
前記デキュー処理の都度、該当キューのキュー監視情報における前記キュー停止判定回数を初期化し、前記キュー監視情報における前記デキュー実行時刻に現在時刻を設定して、前記キュー監視情報における前記キューイングイベント数から１を減算することを特徴とする請求項３または請求項４に記載のキュー監視装置。
【請求項６】
前記キュー監視部は、
前記キューの動作停止を監視する処理を実行した時刻と該当キューの前記キュー監視情報におけるデキュー実行時刻との差分を演算し、前記差分と前記キュー監視情報におけるデキュー未実行時間異常閾値とを周期的に比較し、１回目の異常が判定された場合、該当のキューが保持される機能処理部の即時再起動を抑制し、２回連続して異常が判定された場合、該当のキューが保持される前記機能処理部を再起動することを特徴とする請求項３乃至請求項５の何れか１項に記載のキュー監視装置。
【請求項７】
要求イベントの送受信を行う入出力装置と接続され、前記要求イベントを受信し、少なくとも１個のキューを保持する、複数の機能処理部を有する演算処理装置と、記憶装置とにより構成されるキュー監視装置に用いられるプログラムであって、
前記要求イベントを受信し、前記キューに設定され、前記記憶装置に記憶されるキュー監視情報を更新するとともに前記受信した要求イベントを前記キューの末尾に順番に格納するエンキュー処理ステップと、
前記キュー監視情報を参照して前記キューに１件以上の要求イベントがある場合、前記キューの先頭から順番に取得し、前記キュー監視情報を更新するデキュー処理ステップと、
前記更新されたキュー監視情報に基づき、前記機能処理部が保持するキューの動作停止を所定の周期で監視するキュー停止監視処理ステップと、
をコンピュータに実行させるキュー監視プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、外部から与えられる複数の要求イベントについて、キューを用い順序制御や排他制御を行う、特に、情報通信システムに用いて好適な、キュー監視装置およびキュー監視プログラムに関するものである。
【背景技術】
【０００２】
情報通信技術が飛躍的に発展を遂げた今日では、様々なサービスや業務が情報通信システムによって実現されている。このため、情報システムの内部では、１以上の機能処理部を有し、これら機能処理部では、外部で大量に発生する要求イベントを、適切な順序で、高速に処理し、かつ、要求イベント間で干渉が無く処理結果に矛盾が発生することがないように処理する。このため、各機能処理部は、データを先入れ先出し（ＦＩＦＯ：First In First Out）のリスト構造で保持するいくつかのキューを用い、様々な業務やサービスを提供し、実現する。ここで、キューに要求イベントを積む（順番に格納する）ことをエンキュー（Enqueue）、刈り取る（順番に取得する）ことをデキュー（Dequeue）という。
【０００３】
ところで、前記した情報通信システムでは、各機能処理部で保持するキューが、主な要因としてプログラムバグ等により動作が停止し、要求イベントをデキューできなくなり、要求イベントを処理することができなくなってしまう事象が発生することがある。
この場合、情報通信システムは、キューの動作停止を早期に検出し、回復させなければ、サービスや業務が長時間に亘り停止してしまうことになる。
【０００４】
前記した事象に対する回避策として、従来、キュー監視装置が、キューイングされている要求イベントの数が異常とみなされる閾値に到達したか否かを判定し、異常とみなした場合に該当機能処理部の再起動を実行してキューを初期化することが一般的に行われている。
【０００５】
また、前記した事象に対する回避策として、キュー毎に保留限界時間（タイムアウト）を設定して保留（キューにエンキューされた要求イベントが、デキューされない状態）を開始してから保留経過時間の監視を行い、タイムアウトを検出したときに、そのキューに対応するプログラムが動作していれば、そのタイムアウトが発生したキューのエンキュー情報を次のキューにエンキューし、対応するプログラムが動作していない場合に、そのプログラムを再起動させるトランザクション処理システムも提案されている（例えば、特許文献１参照）。
【特許文献１】特開平２００１−１９５３６０号公報（段落００１４、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、前記した従来技術によれば、キューイングされる要求イベントの数が異常とみなされる閾値（単位時間あたりに要求イベントがキューイングされる頻度）については、その情報通信システムが提供するサービスや業務の特性や、あるいは時節や気候等の様々な条件により大きく変動してしまうため、一意に策定することは困難である。
このため、例えば、閾値を低めに設定した場合は各機能処理部の再起動が実行される頻度が高くなってサービスや業務の円滑な遂行を防げ、一方、閾値を高めに設定した場合はキューの動作が停止してしまった場合にサービスや業務の提供不可能な状態の検出が遅れることになる。
【０００７】
また、前記した特許文献１に開示された技術によれば、トランザクションが一定時間以上キューに保留されないため、同一トランザクション処理における応答時間のバラツキは抑制できるが、発生傾向、および要求に対する応答時間にバラツキのあるトランザクション毎に保留限界時間を設定することは、前記した単位時間あたりのイベント発生頻度によりキューの動作停止判定を行う従来技術と同様に、困難が伴う。
【０００８】
本発明は前記した課題を解決するためになされたものであり、個々のキューに対しキューイングされている要求イベントの数あるいは保留限界時間に依存することなく、プログラムバグ等により動作が停止し、要求イベントをデキューできなくなり、要求イベントを処理することができなくなってしまう事象の発生を抑止することができる、キュー監視装置およびキュー監視プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
前記した課題を解決するために、本発明のキュー監視装置は、入出力信号（要求イベント）の送受信を行う入出力装置と接続され、記憶装置と、演算処理装置とを備え、前記記憶装置の所定の領域に記憶されるキューの動作停止を監視するキュー監視装置であって、前記入出力装置から要求イベントを取得し、前記記憶装置の所定の領域に記憶して処理を行う、少なくとも１個のキューを保持する前記演算処理装置における複数の機能処理部と、前記機能処理部が保持するキューの動作停止を所定の周期で監視する前記演算処理装置におけるキュー監視部と、を備えたものである。
【００１０】
また、本発明のキュー監視プログラムは、入出力信号（要求イベント）の送受信を行う入出力装置と接続され、前記要求イベントを受信し、前記受信した要求イベントを処理する、少なくとも１個のキューを保持する機能処理部を有する演算処理装置と、記憶装置とを備えるキュー監視装置に用いられるプログラムであって、前記要求イベントを受信し、前記キューに設定され、前記記憶装置に記憶されるキュー監視情報を更新するとともに前記受信した要求イベントをキューの末尾に積むエンキュー処理ステップと、前記キュー監視情報を参照して前記キューに１件以上の要求イベントがある場合、前記キューの先頭からデキューして前記キュー監視情報を更新するデキュー処理ステップと、前記更新されたキュー監視情報に基づき、前記機能処理部が保持するキューの動作停止を所定の周期で監視するキュー停止監視処理ステップと、をコンピュータに実行させるものである。
【発明の効果】
【００１１】
本発明によれば、個々のキューに対しキューイングされている要求イベントの数あるいは保留限界時間に依存することなく、プログラムバグ等により動作が停止し、要求イベントをデキューできなくなり、要求イベントを処理することができなくなってしまう事象の発生を抑止することができる、キュー監視装置およびキュー監視プログラムを提供することができる。
【発明を実施するための最良の形態】
【００１２】
図１は、本実施形態に係るキュー監視装置の構成を示すブロック図である。本実施形態に係る情報通信システム１は、入出力装置として使用される端末等、複数の外部装置＃１〜＃３（１０、２０、３０）と、外部装置＃１〜＃３（１０、２０、３０）から発せられるサービス要求を集中処理するセンタ装置１００（キュー監視装置）とが、通信ネットワーク５０経由で接続されている。
【００１３】
センタ装置１００は、演算処理装置１０１と、記憶装置１０２とを備え、外部装置＃１〜＃３（１０、２０、３０）からの入力信号を受信して内部で処理を行い、応答信号（出力信号）を送信することにより所定のサービスまたは業務を実現している。
演算処理装置１０１は、記憶装置１０２の所定の領域に割当てられるプログラム領域（Ｐｒｏｇ）に記憶されたプログラムを逐次読み出し実行することにより、同じく記憶装置１０２の所定の領域に割当てられた作業領域（Ｗｏｒｋ）を使用して後記するエンキュー処理、デキュー処理、ならびにキュー監視処理を行う。
【００１４】
このため、演算処理装置１０１は、図２に示されているように、イベント受信処理部１１０と、イベント処理部１２０と、イベント応答処理部１３０と、キュー監視部１４０との機能を有する。前記したイベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０、ならびにキュー監視部１４０は、いずれもこれらの機能を実現する独立したプログラムモジュールとして記憶装置１０２に記憶されるものである。
なお、図２において、細線矢印は入出力信号、太線矢印はキュー間の信号を示す。
【００１５】
イベント受信処理部１１０は、外部装置＃１〜＃３（１０，２０、３０）からの入力信号を受信してイベント処理部１２０に送信する。イベント処理部１２０は、送信された入力信号によって要求された要求イベントを処理してイベント応答処理部１３０へ送信する。イベント応答処理部１３０は、イベント処理部１２０から送信された処理結果に基づき応答信号（出力信号）を生成し、要求のあった外部装置＃１〜＃３（１０〜３０）に出力する。
また、キュー監視部１４０は、イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０のそれぞれが保持するキュー＃１〜＃３（１１１、１２１、１３１）の動作停止を監視する処理を、イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０のそれぞれが有するキュー監視情報＃１〜＃３（１１２、１２２、１３２）に基づき、所定の周期（例えば１秒）で実行する。
【００１６】
イベント受信処理部１１０は、キュー＃１（１１１）によって、外部装置＃１〜＃３（１０、２０、３０）から送信される入力信号を受信して順序制御を実行する。また、イベント受信処理部１１０は、キュー監視情報＃１（１１２）を保持しており、キュー監視部１４０は、このキュー監視情報＃１（１１２）を用いて、キュー＃１（１１１）に対して、後記するキュー監視処理を実行する。
イベント処理部１２０は、キュー＃２（１２１）によって、イベント受信処理部１１０から送信される信号を受信して順序制御を実行する。また、イベント処理部１２０は、キュー監視情報＃２（１２２）を保持しており、キュー監視部１４０は、このキュー監視情報＃２（１２２）を用いて、キュー＃２（１２１）に対して、後記するキュー監視処理を実行する。
【００１７】
イベント応答処理部１３０は、キュー＃３（１３１）によって、イベント処理部１２０から送信される信号を受信して順序制御を実行する。また、イベント応答処理部１３０は、キュー監視情報＃３（１３２）を保持しており、キュー監視部１４０は、このキュー監視情報＃３（１３２）を用いて、キュー＃３（１３１）に対して、後記するキュー監視処理を実行する。
キュー監視情報＃１〜＃３（１１２、１２２、１３２）は、他の機能処理部（イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０）からも参照可能な記憶装置１０２（図１）上の所定の領域に割当てられ記憶されるものとし、各機能処理部１１０、１２０、１３０は、キュー監視部１４０を周期的に起動することで、キュー監視部１４０によるキュー監視処理を実行するものである。
【００１８】
なお、各機能処理部１１０、１２０、１３０が保持するキュー（それぞれ、キュー＃１（１１１）、＃２（１２１）、＃３（１３１））およびキュー監視情報（それぞれキュー監視情報＃１（１１２）、＃２（１２２）、＃３（１３２））は、記憶装置１０２の作業領域（Ｗｏｒｋ）に割当てられ記憶される。
【００１９】
図３は、キュー監視情報＃１〜＃３（１１２、１２２、１３２）のデータ構造の一例を示す図である。ここでは、キュー監視情報＃１（１１２）のみ例示されているが、他のキュー監視情報＃２、＃３（１２２、１３２）も同様のデータ構造を有するものとする。
キュー監視情報＃１（１１２）は、キューイングイベント数１１２１、デキュー実行時刻１１２２、デキュー未実行時間異常閾値１１２３、およびキュー停止判定回数１１２４の各データ項目を備える
【００２０】
キューイングイベント数１１２１は、各機能処理部１１０、１２０、１３０においてキュー＃１（１１１）、＃２（１２１）、＃３（１３１）にキューイングされている要求イベントの数である。キューイングイベント数１１２１は、初期値が“０”に設定され、エンキューされると“１”が加算され、デキューされると“１”が減算される。
なお、キューイングイベント数１１２１が“０”の場合は、キューイングされた要求イベントはすべてデキューされたことを意味し、キューイングイベント数１１２１が“１”以上の場合は、該当のキュー＃１（１１１）、＃２（１２１）、＃３（１３１）内にデキューされるべき要求イベントが存在していることを意味する。
【００２１】
デキュー実行時刻１１２２は、各機能処理部１１０、１２０、１３０においてそれぞれのキュー＃１（１１１）、＃２（１２１）、＃３（１３１）から要求イベントを刈り取った時刻である。つまり、最後にデキューが行われた時刻が記録されている。ここでは、初期値として、各機能処理部１１０、１２０、１３０によるキュー監視部１４０の起動時刻が設定される。
デキュー未実行時間異常閾値１１２３は、各機能処理部１１０、１２０、１３０における要求イベント１件分を処理するのに十分な時間であり、これは、システムにより事前に設定される。このデキュー未実行時間異常閾値１１２３と、デキュー実行時刻１１２２からキュー停止判定を実行するまでの経過時間との比較を行うことにより、１件の要求イベントを処理するのに十分な時間が経過したにも関わらずデキューされない状態が継続していないかを判定することができる。
【００２２】
キュー停止判定回数１１２４は、初期値として“０”が設定され、キュー監視処理において、最後にデキューされたデキュー実行時刻１１２２からデキュー未実行時間異常閾値１１２３として設定された時間が経過したとみなされた場合に、キュー停止と判定され、“１”が加算される。また、デキュー処理において、要求イベントがデキューされた場合には“０”が設定される。
【００２３】
図４〜図６は、本実施形態に係るキュー監視装置の動作を示すフローチャートであり、エンキュー処理（図４）、デキュー処理（図５）、キュー監視処理（図６）のそれぞれにおけるプログラムの処理手順が示されている。
以下、図４〜図６のフローチャートを参照しながら、図１〜図３に示す本実施形態に係るキュー監視装置の動作について詳細に説明する。
【００２４】
最初に、図４のエンキュー処理から説明する。ここでは、イベント受信処理部１１０によるエンキュー処理を例示して説明する。
【００２５】
センタ装置１００の演算処理装置１０１におけるイベント受信処理部１１０は、外部装置＃１〜＃３（１０、２０、３０）の何れかから要求イベントを受信したとする（ステップＳ４０１）。このとき、イベント受信処理部１１０は、図３にそのデータ構造の一例が示される、キュー監視情報＃１（１１２）のキューイングイベント数１１２１に“１”を加算してキュー監視情報＃１（１１２）の一部内容を更新する（ステップＳ４０２）。そして、イベント受信処理部１１０は、該当キュー＃１（１１１）の末尾に受信した要求イベントを積み（ステップＳ４０３）、エンキュー処理を終了する。
【００２６】
なお、前記した例は、イベント受信処理部１１０におけるエンキュー処理について説明したが、イベント処理部１２０、イベント応答処理部１３０についても、イベント受信処理部１１０、イベント処理部１２０のそれぞれから要求イベントを受信し、対応するキュー監視情報＃２（１２２）、＃３（１３２）を更新して、該当のキュー＃２（１２１）、＃３（１３１）に要求イベントを積む他は、前記したイベント受信処理部１１０と同様のエンキュー処理を行う。
このように、各機能処理部１１０、１２０、１３０が、前記した一連の処理を、要求イベントを受信する毎に実行することで、それぞれのキュー監視情報＃１〜＃３（１１２、１２２、１３２）のキューイングイベント数１１２１には、現在キューイングされている要求イベントの数が記録されていることになる。
【００２７】
次に、図５のデキュー処理について説明する。ここでも図４に示すエンキュー処理同様、イベント受信処理部１１０によるデキュー処理を例示して説明する。
【００２８】
イベント受信処理部１１０は、イベント処理部１２０から要求イベントのデキュー要求を受信し（ステップＳ５０１）、キュー監視情報＃１（１１２）のキューイングイベント数１１２１を判定する（ステップＳ５０２）。
ここで、キューイングイベント数１１２１が“０”の場合（ステップＳ５０２“＝０”）、イベント受信処理部１１０は、キュー＃１（１１１）に要求イベントがキューイングされたことを検出したか否かを判定する（ステップＳ５０３）。一方、ステップＳ５０２のキューイングイベント数判定処理において、キューイングイベント数１１２１が“１”以上の場合（ステップＳ５０２“＞０”）、もしくはステップＳ５０３の判定処理において要求イベントがキューイングされたことを検出した場合（ステップＳ５０３“Ｙｅｓ”）、イベント受信処理部１１０は、該当キュー＃１（１１１）の先頭位置から要求イベントを刈り取る（ステップＳ５０４）。
【００２９】
続いて、イベント受信処理部１１０は、対応するキュー監視情報＃１（１１２）のキュー停止判定回数１１２４を“０”に設定する（ステップＳ５０５）。また、イベント受信処理部１１０は、不図示の内部時計から現在時刻を取得し、その現在時刻をキュー監視情報＃１（１１２）のデキュー実行時刻１１２２に記録する（ステップＳ５０６）。
次に、イベント受信処理部１１０は、キュー監視情報＃１（１１２）のキューイングイベント数１１２１に記録された値から“１”を減算して内容を更新する（ステップＳ５０７）。そして、イベント受信処理部１１０は、ステップＳ５０４で刈り取った要求イベントに対応する処理を実行し（ステップＳ５０８）、処理後の要求イベントをイベント処理部１２０に送信し（ステップＳ５０９）、デキュー処理は完了する。
デキュー処理完了後、新たに要求イベントを受信したイベント受信処理部１１０は、前記した一連（ステップＳ５０１〜Ｓ５０９）の処理を繰り返し実行する。
【００３０】
前記したイベント受信処理部１１０の他、イベント処理部１２０、イベント応答処理部１３０は、前記したデキュー処理をイベント受信処理部１１０と同様に繰り返し実行する。そのことにより、対応するそれぞれのキュー監視情報＃１〜＃３（１１２）のキューイングイベント数１１２１には、現在、該当のキュー＃１〜＃３（１１１、１２１、１３１）にキューイングされている要求イベントの数が記録され、デキュー実行時刻１１２２には、最後にデキューが実行された時刻がそれぞれ記録されることになる。
【００３１】
最後に、図６のフローチャートを参照しながら、キュー監視部１４０によるキュー監視処理について詳細に説明する。ここでも、図４、図５同様、イベント受信処理部１２０が保持するキュー＃１（１１１）を例示して説明する。
キュー監視部１４０は、例えば、１秒周期のキュー監視タイミングになると（ステップＳ６０１“Ｙｅｓ”）、キュー監視情報＃１（１１２）のキューイングイベント数１１２１を判定する（ステップＳ６０２）。ここで、キューイングイベント数１１２１が“０”の場合（ステップＳ６０２“＝０”）、キュー監視部１４０は、すべての要求イベントがデキューされ、および処理が完了しているものと判定し、次のキュー監視タイミングまで（１秒間）スリープする（ステップＳ６０９）。なお、ここで、「スリープ」とは、通常、パソコン等で用いられているように、一定時間入力が無い場合にモニタの電源を切り、あるいはハードディスクの電源を切って使用する電力を節約する動作モードをいうのではなく、単に作業の準備をしたまま待機している待機モードをいう。
【００３２】
前記したステップＳ６０２のキューイングイベント数判定処理において、キュー監視情報＃１(１１２)に記録されたキューイングイベント数１１２１が“１”以上であった場合（ステップＳ６０２“＞０”）、キュー監視部１４０は、キュー＃１（１１１）内に未だデキューされていない要求イベントが存在すると判定し、内部時計から現在時刻を取得する（ステップＳ６０３）。
続いて、キュー監視部１４０は、前記により取得した現在時刻から、キュー監視情報＃１（１１２）のデキュー実行時刻１１２２に記録された時刻を減算することにより“差分Ｄ”を求める（ステップ６０４）。そして、キュー監視部１４０は、ステップＳ６０４で算出された“差分Ｄ”と、キュー監視情報１１２のキュー未実行時間異常閾値１１２３に記録された値とを比較する（ステップＳ６０５）。
【００３３】
ここで、“差分Ｄ”が、キュー監視情報＃１（１１２）のキュー未実行時間異常閾値１１２３に記録された値以下の場合（ステップＳ６０５“差分Ｄ≦異常閾値”）、キュー監視部１４０は、現在処理中の要求イベントがあり、実行完了後にデキューされるため、キュー＃１（１１１）は停止していないものと判定して、次の監視期間まで１秒間、スリープする（ステップＳ６０９）。
ステップＳ６０５の比較処理において、“差分Ｄ”が、キュー未実行時間異常閾値１１２３に記録された値よりも大きい場合（ステップＳ６０５“差分Ｄ＞異常閾値”）、エンキュー直後のデキュー実行前に割込んでキュー監視処理が実行されている可能性があるため、キュー監視部１４０は、イベント受信処理部１１０を即時に再起動することはせず、キュー監視情報＃１（１１２）のキュー停止判定回数１１２４に“１”を加算して記録値を更新する（ステップＳ６０６）。
【００３４】
続いて、キュー監視部１４０は、キュー監視情報＃１（１１２）のキュー停止判定回数１１２４に記録された値を判定する（ステップＳ６０７）。ここで、キュー停止判定回数１１２４に記録された値が“１”である場合（ステップＳ６０７“＝１”）、エンキュー直後のデキュー実行前に割込んでキュー監視処理が実行されたものと判定されるため、キュー監視部１４０は、次の監視周期まで１秒間スリープする（ステップＳ６０９）。この１秒間の間にデキュー処理が実行されれば、図５のデキュー処理に示すステップＳ５０５においてキュー停止判定回数１１２４に“０”が設定されることになる。
【００３５】
一方、ステップＳ６０７のキュー停止判定処理において、キュー監視情報＃１（１１２）のキュー停止判定回数１１２４に記録された値が“１”よりも大きい場合には（ステップＳ６０７“＞１”）、最後にデキューした時刻から、キュー未実行時間異常閾値１１２３に記録された時間が経過したと判定され、また、その判定時点ではエンキュー直後のデキュー実行前に割込んでキュー監視処理が実行された可能性がある。このため、キュー監視部１４０は、これらから更に１秒経過後の判定でもデキューが実行されていなかったとみなし、キュー＃１（１１１）の動作が停止したと判定し、イベント受信処理部１１０を再起動して対応するキュー＃１（１１１）の初期化を実行する（ステップＳ６０８）。
【００３６】
なお、前記したキュー監視処理は、イベント受信処理部１１０が保持するキュー＃１（１１１）についてのみ説明したが、キュー監視部１４０は、イベント処理部１２０が保持するキュー＃２（１２１）、イベント応答処理部１３０が保持するキュー＃３（１３１）についても同様の処理を行う。
前記したように、キュー監視部１４０は、各機能処理部（イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０）が保持するキュー＃１〜＃３（１１１、１２１、１３１）について、ステップＳ６０１〜Ｓ６０９で示されるキュー監視処理を、例えば、１秒周期で実行することによって、キュー＃１〜＃３（１１１、１２１、１３１）に要求イベントがキューイングされた状態でデキューが実行されない状態が継続しているかいないかを判定し、キューの動作が停止したか否かの監視を実行することができる。
【００３７】
前記したように、本実施形態に係るキュー監視装置は、図４にフローチャートで示したエンキュー処理と、図５に示したデキュー処理とを各機能処理部（イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０）のそれぞれにおいて実行し、キュー監視部１４０が、各機能処理部で保持するキュー監視情報＃１〜＃３（１１２、１２２、１３２）を用い、図６にフローチャートで示したキュー監視処理を実行することにより、それぞれの機能処理部が保持するキュー＃１〜＃３（１１１、１２１、１３１）のそれぞれに対するキュー停止監視処理を実現するものである。
したがって、本実施形態に係るキュー監視装置によれば、キュー監視機能部１４０が、各機能処理部が保持する個々のキュー＃１〜＃３（１１１、１２１、１３１）毎に、それぞれのキュー監視情報＃１〜＃３（１１２、１２２、１３２）を周期的（例えば、１秒間隔）に参照することにより、キューイングされた要求イベントの数に依存することなく、各キュー＃１〜＃３（１１１、１２１、１３１）の動作停止を監視することが可能になる。このため、プログラムバグ等により動作が停止し、要求イベントをデキューできなくなり、要求イベントを処理することができなくなってしまう事象の発生を抑止することができる。
【００３８】
なお、前記した本実施形態に係るキュー監視装置によれば、演算処理装置１０１が実行するプログラムの構造として、イベント受信機能部１１０、イベント処理部１２０、イベント応答処理部１３０の３つの機能処理部を有するものとして説明したが、各機能を備えていれば、３つに制限されるものではなく、３個以上でも以下でもよく、数の制限はない。
また、本実施形態に係るキュー監視装置によれば、各機能処理部（イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０）がそれぞれで単数のキュー＃１〜＃３（１１１、１２１、１３１）を保持する構成について説明したが、各機能処理部内に複数のキューを保持する構成とした場合も同様、それぞれのキューにキュー監視情報＃１〜＃３（１１２、１２２、１３２）を割当て、キュー監視部１４０がそれぞれのキュー監視情報＃１〜＃３（１１２、１２２、１３２）を定期的に参照することによりキューの停止監視が可能になる。
【００３９】
また、前記した本実施形態に係るキュー監視装置によれば、通信ネットワーク５０を用いた情報通信システム１に適用した場合のみ例示したが、通信ネットワーク５０によらず、ＰＣ等の入出力装置と、記憶装置を含む演算処理装置とが内部バスを介して接続されるスタンドアロン構成の情報処理装置においても同様に適用が可能である。
【００４０】
また、図１に示したセンタ装置１００（演算処理装置１０１）が有する構成は、すべてをソフトウェアによって実現しても、あるいはその少なくとも一部をハードウェアで実現してもよい。
例えば、センタ装置１００は、入出力装置（外部装置＃１〜＃３）から要求イベントを取得（受信）し、記憶装置の所定の領域に記憶して、要求イベントを処理する、それぞれが少なくとも１個のキューを保持する、演算処理装置１０１が有する複数の機能処理部（図２、イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０）と、それぞれの機能処理部が保持するキューの動作停止を所定の周期で監視する、演算処理装置１０１が有するキュー監視部１４０（図２）とを備える。キュー監視部１４０におけるデータ処理は、１または複数のプログラムによりコンピュータ上で実現してもよく、また、その少なくとも一部をハードウェアで実現してもよい。
【００４１】
また、本実施形態に係るキュー監視プログラムは、例えば、図１において、要求イベントの送受信を行う入出力装置（外部装置＃１〜＃３（１０、２０、３０））と接続され、前記入出力装置からの要求イベントを受信し、処理し、要求のあった前記入出力装置に応答する、それぞれが少なくとも１個のキュー（図２、キュー＃１（１１１）、キュー＃２（１２１）、キュー＃３（１３１））を保持する機能処理部（図２、イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０）を有する演算処理装置１０１と、記憶装置とを備えるキュー監視装置（センタ装置１００）に用いられるプログラムである。例えば、図４〜図６のフローチャートにおいて、前記要求イベントを受信し、前記それぞれのキューに設定され、前記記憶装置に記憶されるキュー監視情報を更新するとともに、前記受信した要求イベントをキュー末尾に積むエンキュー処理ステップ（図４のフローチャートのステップＳ４０１〜Ｓ４０３）と、前記キュー監視情報を参照して１以上のキューイングイベントがある場合、先頭からデキューして前記キュー監視情報を更新するとともに、前記要求イベントに対応する処理を実行するデキュー処理ステップ（図５のフローチャートのステップＳ５０１〜Ｓ５０９）と、前記更新されたキュー監視情報に基づき、前記それぞれの機能処理部が保持するキューの停止監視を所定の周期で実行するキュー停止監視処理ステップ（図６のフローチャートのステップＳ６０１〜Ｓ６０９）と、をコンピュータ（図１のセンタ装置１００）に実行させるものである。
【００４２】
例えば、本実施形態に係るキュー監視プログラムは、図３にてキュー監視情報＃１〜＃３（１１２、１２２、１３２）のそれぞれのデータ構造の一例が示されるように、キュー内に存在する要求イベントの数を示すキューイングイベント数１１２１と、最後のキューから要求イベントがデキューされた時刻を示すデキュー実行時刻１１２２と、要求イベント１件分を処理するのに十分な時間でありその時間内にデキューされないことは異常な状態であると判定することができるデキュー未実行時間異常閾値１１２３と、デキューが実行されない異常な状態と判定された回数を示すキュー停止判定回数１１２４との、各データ項目を備える。そして、キュー監視プログラムは、図４にてフローチャートで示されるように、エンキュー処理時、キューイングイベント数１１２１に“１”を加算する処理を行い、また、図５にフローチャートで示すように、エンキュー処理時に、キュー停止判定回数１１２４に“０”を設定し、デキュー実行時刻に現在時刻を設定し、キューイングイベント数１１２１から“１”を減算する処理を行い、キュー監視情報を更新するものである。
【００４３】
そして、本実施形態に係るキュー監視プログラムは、図６にフローチャートで示されるように、キュー監視処理を行うにあたり、実際の監視時刻とデキュー実行時刻の差分と、デキュー未実行時間異常閾値１１２３とを比較することにより、デキューが実行されずにいる時間が異常であるかどうかを判定する。更に、デキューが実行されずにいる時間が異常であるとはじめて判定された場合に、エンキュー直後のデキュー前に割込んでキュー監視処理が実行された可能性があることを考慮して、すぐには該当のキューが保持される処理機能部（イベント受信処理部１１０、イベント処理部１２０、イベント応答処理部１３０）を再起動しない。そして、デキューが実行されずにいる時間が異常であると２周期連続で判定された場合に、キューが停止したと判定し、該当のキューを保持する機能処理部を再起動するものである。
【００４４】
前記した本実施形態に係るキュー監視プログラムによれば、内部に少なくとも１個のプログラムモジュール（各機能処理部１１０、１２０、１３０に相当する）を有し、このプログラムモジュールにおいて少なくとも１個のキューを保持し、かつ、これらキューの動作を監視するために、各プログラムモジュールにより参照可能なキュー監視情報＃１〜＃３（１１２、１２２、１３２）を参照して、例えば１秒周期でキュー監視処理を実行することにより、個々のキューに対しキューイングされている要求イベントの数あるいは保留限界時間に依存することなく、プログラムバグ等により動作が停止し、要求イベントをデキューできなくなり、要求イベントを処理することができなくなってしまう事象の発生を抑止することができる。
【図面の簡単な説明】
【００４５】
【図１】本実施形態に係るキュー監視装置の構成を示すブロック図である。
【図２】本実施形態に係るキュー監視装置の演算制御装置の機能を示す図である。
【図３】本実施形態に係るキュー監視装置の各機能処理部が有するキュー監視情報のデータ構造の一例を示す図である。
【図４】本実施形態に係るキュー監視装置の動作を示すフローチャートであり、エンキュー処理における処理手順を示す。
【図５】本実施形態に係るキュー監視装置の動作を示すフローチャートであり、デキュー処理における処理手順を示す。
【図６】本実施形態に係るキュー監視装置の動作を示すフローチャートであり、キュー監視処理における処理手順を示す。
【符号の説明】
【００４６】
１      情報通信システム
１０、２０、３０  外部装置（入出力装置）
５０    通信ネットワーク
１００  センタ装置（キュー監視装置）
１０１  演算処理装置
１０２  記憶装置
１１０  イベント受信処理部
１２０  イベント処理部
１３０  イベント応答処理部
１４０  キュー監視部
１１１、１２１、１３１  キュー＃１〜＃３
１１２、１２２、１３２  キュー監視情報＃１〜＃３
１１２１  キューイングイベント数
１１２２  デキュー実行時刻
１１２３  デキュー未実行時間異常閾値
１１２４  キュー停止判定回数
【図１】
2010003212.tif 000003
【図２】
2010003212.tif 000004
【図３】
2010003212.tif 000005
【図４】
2010003212.tif 000006
【図５】
2010003212.tif 000007
【図６】
2010003212.tif 000008