(57)【要約】【課題】ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を事前に察知し、アプリケーションのハングアップを回避することを目的とする。【解決手段】アラーム指定値と、イベント通知オブジェクトとを登録し、リソース現在値がアラーム指定値に達していると判定された場合、アラーム指定値に対応するイベント通知オブジェクトに、リソース現在値がアラーム指定値に達したことを示すイベントを通知することによって課題を解決する。【選択図】図２
2008123211.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションから、システムのリソース現在値が任意の値に達したことを知るために前記任意の値として指定するアラーム指定値と、前記リソース現在値が前記アラーム指定値に達したことを示すイベントの通知を行うイベント通知オブジェクトと、を取得し、前記アラーム指定値と、前記イベント通知オブジェクトと、をアラーム情報管理テーブルに登録するイベント通知オブジェクト登録手段と、
システムのリソース現在値を取得するリソース情報取得手段と、
前記アラーム情報管理テーブルから前記アラーム指定値と、前記イベント通知オブジェクトと、を取得するアラーム情報取得手段と、
前記アラーム情報取得手段が取得した前記アラーム指定値と、前記リソース情報取得手段が取得した前記リソース現在値と、を比較して、前記リソース現在値が前記アラーム指定値に達しているか否かを判定するアラーム判定手段と、
前記アラーム判定手段において前記リソース現在値が前記アラーム指定値に達していると判定された場合、前記アラーム指定値に対応する、前記アラーム情報取得手段が取得した前記イベント通知オブジェクトに、前記リソース現在値が前記アラーム指定値に達したことを示すイベントを通知するイベント通知手段と、
を有することを特徴とするリソース監視装置。
【請求項２】
前記イベント通知オブジェクト登録手段は、前記アプリケーションから取得した前記イベント通知オブジェクトが前記アラーム情報管理テーブルに既に登録されていた場合、前記イベント通知オブジェクトと、前記アプリケーションから取得した前記アラーム指定値と、を前記アラーム情報管理テーブルに再設定することを特徴とする請求項１に記載のリソース監視装置。
【請求項３】
アプリケーションから、前記アラーム指定値と、前記イベント通知オブジェクトと、を取得し、前記イベント通知オブジェクトが前記アラーム情報管理テーブルに既に登録されていた場合、前記イベント通知オブジェクトと、前記アラーム指定値と、を前記アラーム情報管理テーブルから削除するイベント通知オブジェクト削除手段を更に有することを特徴とする請求項１又は２に記載のリソース監視装置。
【請求項４】
前記リソース情報取得手段は、前記リソース現在値を取得するときは、前記システムのメモリ確保の機能を停止することを特徴とする請求項１乃至３の何れか１項に記載のリソース監視装置。
【請求項５】
リソース監視装置におけるリソース監視方法であって、
アプリケーションから、システムのリソース現在値が任意の値に達したことを知るために前記任意の値として指定するアラーム指定値と、前記リソース現在値が前記アラーム指定値に達したことを示すイベントの通知を行うイベント通知オブジェクトと、を取得し、前記アラーム指定値と、前記イベント通知オブジェクトと、をアラーム情報管理テーブルに登録するイベント通知オブジェクト登録工程と、
システムのリソース現在値を取得するリソース情報取得工程と、
前記アラーム情報管理テーブルから前記アラーム指定値と、前記イベント通知オブジェクトと、を取得するアラーム情報取得工程と、
前記アラーム情報取得工程において取得された前記アラーム指定値と、前記リソース情報取得工程において取得された前記リソース現在値と、を比較して、前記リソース現在値が前記アラーム指定値に達しているか否かを判定するアラーム判定工程と、
前記アラーム判定工程において前記リソース現在値が前記アラーム指定値に達していると判定された場合、前記アラーム指定値に対応する、前記アラーム情報取得手段が取得した前記イベント通知オブジェクトに、前記リソース現在値が前記アラーム指定値に達したことを示すイベントを通知するイベント通知工程と、
を有することを特徴とするリソース監視方法。
【請求項６】
前記イベント通知オブジェクト登録工程では、前記アプリケーションから取得した前記イベント通知オブジェクトが前記アラーム情報管理テーブルに既に登録されていた場合、前記イベント通知オブジェクトと、前記アプリケーションから取得した前記アラーム指定値と、を前記アラーム情報管理テーブルに再設定することを特徴とする請求項５に記載のリソース監視方法。
【請求項７】
アプリケーションから、前記アラーム指定値と、前記イベント通知オブジェクトと、を取得し、前記イベント通知オブジェクトが前記アラーム情報管理テーブルに既に登録されていた場合、前記イベント通知オブジェクトと、前記アラーム指定値と、を前記アラーム情報管理テーブルから削除するイベント通知オブジェクト削除工程を更に有することを特徴とする請求項５又は６に記載のリソース監視方法。
【請求項８】
前記リソース情報取得工程では、前記リソース現在値を取得するときは、前記システムのメモリ確保の機能を停止することを特徴とする請求項５乃至７の何れか１項に記載のリソース監視方法。
【請求項９】
請求項５乃至８の何れか１項に記載のリソース監視方法をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、リソース監視装置及びリソース監視方法に関する。
【背景技術】
【０００２】
リソースオーバーに陥ったとき、アプリケーションのハングアップを回避する処理として、システムがメモリ不足エラーをアプリケーションに通知し、アプリケーションの処理を中断させる技術が知られている（例えば、非特許文献１参照）。なお、以降、メモリ不足エラーのことを、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒと表記する。
【０００３】
【非特許文献１】Ｊａｖａ（登録商標）ＴＭ  ２  ＳＤＫ，  Ｓｔａｎｄａｒｄ  Ｅｄｉｔｉｏｎ  ドキュメント
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のシステムでは、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を事前に察知することができなかった。このため、リソースオーバーに陥り、システムがアプリケーションにＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを通知しても、アプリケーションが正常にリソース不足に対処する処理を行える保証はなかった。
【０００５】
本発明はこのような問題点に鑑みなされたもので、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を事前に察知し、アプリケーションのハングアップを回避することを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明は、アプリケーションから、システムのリソース現在値が任意の値に達したことを知るために前記任意の値として指定するアラーム指定値と、前記リソース現在値が前記アラーム指定値に達したことを示すイベントの通知を行うイベント通知オブジェクトと、を取得し、前記アラーム指定値と、前記イベント通知オブジェクトと、をアラーム情報管理テーブルに登録するイベント通知オブジェクト登録手段と、システムのリソース現在値を取得するリソース情報取得手段と、前記アラーム情報管理テーブルから前記アラーム指定値と、前記イベント通知オブジェクトと、を取得するアラーム情報取得手段と、前記アラーム情報取得手段が取得した前記アラーム指定値と、前記リソース情報取得手段が取得した前記リソース現在値と、を比較して、前記リソース現在値が前記アラーム指定値に達しているか否かを判定するアラーム判定手段と、前記アラーム判定手段において前記リソース現在値が前記アラーム指定値に達していると判定された場合、前記アラーム指定値に対応する、前記アラーム情報取得手段が取得した前記イベント通知オブジェクトに、前記リソース現在値が前記アラーム指定値に達したことを示すイベントを通知するイベント通知手段と、を有することを特徴とする。
【０００７】
また、本発明は、リソース監視方法及びプログラムとしてもよい。
【発明の効果】
【０００８】
本発明によれば、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を事前に察知し、アプリケーションのハングアップを回避することができる。
【発明を実施するための最良の形態】
【０００９】
＜実施形態１＞
以下、本発明の実施形態１を、図１〜図８を参照しながら説明する。
まず、以下で使用する用語を定義する。
アラーム指定値とは、アプリケーションが、システムのリソース現在値が任意の値に達したことを知るために、前記任意の値として指定するものである。このアラーム指定値は、アプリケーションが指定したシステムのリソース残量ともいうことができる。
また、リソース現在値とは、システムのリソース残量のことである。即ち、現時点でアプリケーションが利用可能なリソース量のことを指す。リソースの具体例として本実施形態では、メモリ残量、ディスク使用量、ファイルディスクリプタ同時接続数、ソケット使用数を挙げているが、これらに限定されるものではない。
【００１０】
図１は、リソース監視システムのハードウェア構成を示すブロック図である。
リソース監視装置の一例であるリソース監視システムは、コンピュータ装置で実現してもよいし、コンピュータ装置と同等の機能構成をもつデジタル複合機、デジタルテレビ、ＦＡＸ、デジタルカメラ、デジタルカムコーダ等の組込み装置で実現してもよい。
【００１１】
１０１は、リソース監視システム１００全体を制御するＣｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）である。１０２は、変更を必要としないプログラムやパラメータを格納するＲｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ（ＲＯＭ）である。１０３は、外部装置等から供給されるプログラムやデータを一時記憶するＲａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ（ＲＡＭ）である。１０４は、リソース監視システム１００に固定して設置されたハードディスクやメモリカード、或いはリソース監視システム１００から着脱可能なフレキシブルディスク（ＦＤ）やＣｏｍｐａｃｔ  Ｄｉｓｋ（ＣＤ）等の光ディスク、等を含む外部記憶装置である。なお、外部記憶装置１０４は、磁気や光カード、ＩＣカード、メモリカード等であってもよい。１０５は、インターネット等のネットワーク回線に接続するためのネットワークインタフェイスである。
【００１２】
図２は、リソース監視システム１００の機能構成を示すブロック図である。リソース監視部２００は、本実施形態のリソース監視システム１００において、イベント通知オブジェクトの取得、アラーム指定値とリソース現在値との比較及びイベントの配信等を実行するプログラムである。
【００１３】
リソース監視部２００は、イベント通知オブジェクト登録部２０８、イベント通知オブジェクト削除部２０９、アラーム判定部２１０、リソース情報取得部２１１、イベント通知部２１２、アラーム情報取得部２１７を有する。また、リソース監視部２００は、アラーム情報管理テーブル（メモリ用）２１３、アラーム情報管理テーブル（ディスク用）２１４、アラーム情報管理テーブル（ファイルディスクリプタ用）２１５、アラーム情報管理テーブル（ソケット用）２１６を有する。これらの詳細は以下に説明する。
【００１４】
アプリケーション（Ａ）２０１、アプリケーション（Ｂ）２０２、アプリケーション（Ｃ）２０３は、アプリケーションプラットフォーム２０７上でひとつのプロセスとして動作するアプリケーションである。
【００１５】
アラーム指定値２０４は、アプリケーション（Ａ）２０１が指定したアラーム指定値である。アラーム指定値２０４は、アプリケーション（Ａ）２０１からリソース監視部２００に渡される。
【００１６】
イベント通知オブジェクト２０５は、アプリケーション（Ａ）２０１がアプリケーションプラットフォーム２０７から通知を受けるためのアプリケーションオブジェクトである。イベント通知オブジェクト２０５は、アプリケーション（Ａ）２０１からリソース監視部２００に渡される。
【００１７】
アプリケーション管理マネージャー２０６は、アプリケーションのインストール、起動、停止、アンインストールを実行する。また、任意のアプリケーションは、サービスと呼ばれる特有の機能をもたせたアプリケーションオブジェクトをアプリケーション管理マネージャー２０６に登録することによって、前記サービスを他のアプリケーションに提供することができる。本実施形態では、アプリケーションがリソース監視部２００にアラーム指定値２０４及びイベント通知オブジェクト２０５を登録するためのサービスを、リソース監視部２００がアプリケーション管理マネージャー２０６に登録している。
【００１８】
アプリケーションプラットフォーム２０７は、アプリケーションの実行環境である。実行環境上では複数のアプリケーションがひとつのプロセス上で動作可能である。
【００１９】
アラーム情報管理テーブル（メモリ用）２１３は、リソース監視部２００に登録されたメモリのアラーム指定値２０４、イベント通知オブジェクト２０５及び状態フラグを管理するテーブルである。イベント通知オブジェクト２０５、アラーム指定値２０４及び状態フラグは関連付けられてアラーム情報管理テーブルに格納される。状態フラグについては、後述の図４で説明する。
【００２０】
アラーム情報管理テーブル（ディスク用）２１４は、リソース監視部２００に登録されたディスクのアラーム指定値２０４、イベント通知オブジェクト２０５及び状態フラグを管理するテーブルである。
【００２１】
アラーム情報管理テーブル（ファイルディスクリプタ用）２１５は、リソース監視部２００に登録されたファイルディスクリプタのアラーム指定値２０４、イベント通知オブジェクト２０５及び状態フラグを管理するテーブルである。
【００２２】
アラーム情報管理テーブル（ソケット用）２１６は、リソース監視部２００に登録されたソケットのアラーム指定値２０４、イベント通知オブジェクト２０５及び状態フラグを管理するテーブルである。
【００２３】
図３は、実施形態１において、リソース監視部２００がイベント通知オブジェクトを登録するためのインタフェース・サービスを提供する処理の一例を示すフローチャートである。
【００２４】
リソース監視部２００は、アラーム情報管理テーブルを初期化する（Ｓ３０１）。本実施形態においては、アラーム情報管理テーブル（メモリ用）２１３、アラーム情報管理テーブル（ディスク用）２１４、アラーム情報管理テーブル（ファイルディスクリプタ用）２１５、アラーム情報管理テーブル（ソケット用）２１６を初期化する。
【００２５】
リソース監視部２００は、アプリケーション（Ａ）２０１にイベント通知オブジェクト２０５を登録させるためのインタフェース・サービスを提供する（Ｓ３０２）。より具体的に説明すると、リソース監視部２００は、アプリケーション管理マネージャー２０６に、アプリケーション（Ａ）２０１がイベント通知オブジェクト２０５及びアラーム指定値２０４を登録するためのインタフェース・サービスを登録する。アプリケーション（Ａ）２０１は、インタフェース・サービスをアプリケーション管理マネージャー２０６から取得し、インタフェース・サービスを通じて、イベント通知オブジェクト２０５及びアラーム指定値２０４をリソース監視サービス１００に登録する。これらの操作によって、リソース監視部２００は、アプリケーション（Ａ）２０１からアラーム指定値２０４及びイベント通知オブジェクト２０５を取得することが可能となる。
【００２６】
図４は、実施形態１におけるリソース監視部２００のイベント通知オブジェクト登録部２０８による処理の一例を示すフローチャートである。
【００２７】
イベント通知オブジェクト登録部２０８は、アプリケーション（Ａ）２０１から取得したアラーム指定値２０４及びイベント通知オブジェクト２０５を、リソースに対応するアラーム情報管理テーブル２１３、２１４、２１５又は２１６に登録する部である。なお、以下では図４の説明において、説明の簡略化のため、イベント通知オブジェクト登録部２０８ではなく、リソース監視部２００が処理を行うものとして説明を行う。
【００２８】
リソース監視部２００は、アプリケーション（Ａ）２０１からアラーム指定値２０４及びイベント通知オブジェクト２０５を取得する（Ｓ４０１）。同時にアプリケーション（Ａ）２０１は、リソースに対応するアラーム情報管理テーブル２１３、２１４、２１５又は２１６を指定する。
【００２９】
アプリケーション（Ａ）２０１によってアラーム情報管理テーブル（メモリ用）２１３が指定された場合（Ｓ４０２でメモリを選択）、リソース監視部２００は、Ｓ４０３に進む。Ｓ４０３において、リソース監視部２００は、処理対象のアラーム情報管理テーブルとしてアラーム情報管理テーブル（メモリ用）２１３をセットする。
【００３０】
同様に、アプリケーション（Ａ）２０１によってアラーム情報管理テーブル（ディスク用）２１４が指定された場合（Ｓ４０２でディスクを選択）、リソース監視部２００は、Ｓ４０４に進む。Ｓ４０４において、リソース監視部２００は、処理対象のアラーム情報管理テーブルとしてアラーム情報管理テーブル（ディスク用）２１４をセットする。
【００３１】
同様に、アプリケーション（Ａ）２０１によってアラーム情報管理テーブル（ファイルディスクリプタ用）２１５が指定された場合（Ｓ４０２でファイルディスクリプタを選択）、リソース監視部２００は、Ｓ４０５に進む。Ｓ４０５において、リソース監視部２００は、処理対象のアラーム情報管理テーブルとしてアラーム情報管理テーブル（ファイルディスクリプタ用）２１５をセットする。
【００３２】
同様に、アプリケーション（Ａ）２０１によってアラーム情報管理テーブル（ソケット用）２１６が指定された場合（Ｓ４０２でソケットを選択）、リソース監視部２００は、Ｓ４０６に進む。Ｓ４０６において、リソース監視部２００は、処理対象のアラーム情報管理テーブルとしてアラーム情報管理テーブル（ソケット用）２１６をセットする。
【００３３】
Ｓ４０７において、リソース監視部２００は、状態フラグを初期化する。状態フラグとは、アプリケーションプラットフォーム２０７のリソース状態を示す。より具体的に説明すると、アプリケーションプラットフォーム２０７のリソース現在値がアプリケーション（Ａ）２０１から取得したアラーム指定値２０４を下回った場合、状態フラグは「アラーム」になる。状態フラグが「アラーム」の場合、アプリケーション（Ａ）２０１のアラーム指定値２０４に対して、アプリケーションプラットフォーム２０７のリソース現在値が不足していることを意味する。以下、アプリケーションプラットフォーム２０７の状態フラグ＝アラームであるとき、「アラーム状態」と呼ぶことにする。逆に、アプリケーションプラットフォーム２０７のリソース現在値がアラーム指定値２０４を上回った場合、状態フラグは「ノーマル」になる。状態フラグが「ノーマル」の場合、アプリケーション（Ａ）２０１のアラーム指定値２０４に対して、アプリケーションプラットフォーム２０７のリソースが確保可能なことを意味する。以下、アプリケーションプラットフォーム２０７の状態フラグ＝ノーマルであるとき、「ノーマル状態」と呼ぶことにする。
【００３４】
初期化時の値には、リソース監視部２００は、取得したアラーム指定値２０４がリソース現在値を下回った場合は「アラーム」を、上回った場合は「ノーマル」を、状態フラグにセットする。前記状態フラグは、各イベント通知オブジェクト２０５に関連付けられてアラーム情報管理テーブルに格納されている。
【００３５】
リソース監視部２００は、イベント通知オブジェクト２０５、アラーム指定値２０４及び状態フラグをアラーム情報管理テーブルに登録する（Ｓ４０８）。
【００３６】
図３、図４に示した処理によって、リソース監視部２００は、アプリケーション（Ａ）２０１から取得したイベント通知オブジェクト２０５及びアラーム指定値２０４をアラーム情報管理テーブル２１３、２１４、２１５又は２１６に登録することができる。
【００３７】
次に、本実施形態のリソース監視部２００が、リソース現在値とアラーム指定値２０４とを比較して、アプリケーションプラットフォーム２０７の状態がアラーム状態であるか、又は、ノーマル状態であるかを判定する処理を説明する。また、アプリケーションプラットフォーム２０７の状態が、アラーム状態からノーマル状態、ノーマル状態からアラーム状態に遷移したとき、アプリケーション（Ａ）２０１にイベントを通知する処理についても説明する。
【００３８】
図５は、実施形態１において、リソース監視部２００がアプリケーションプラットフォーム２０７の状態を判定し、イベントを通知する処理の一例を示すフローチャートである。図５に示される処理は、イベント通知オブジェクト登録部２０８によって開始される。
【００３９】
リソース監視部２００（又はイベント通知オブジェクト登録部２０８）は、アラーム情報管理テーブルにアラーム情報管理テーブル（メモリ用）２１３を指定する（Ｓ５０１）。続いて、リソース監視部２００は、イベント通知処理に進む（Ｓ５０２）。イベント通知処理は、図６で後述する。
【００４０】
同様に、リソース監視部２００は、アラーム情報管理テーブルにアラーム情報管理テーブル（ディスク用）２１４を指定する（Ｓ５０３）。続いて、リソース監視部２００は、イベント通知処理に進む（Ｓ５０４）。
【００４１】
同様に、リソース監視部２００は、アラーム情報管理テーブルにアラーム情報管理テーブル（ファイルディスクリプタ用）２１５を指定する（Ｓ５０５）。続いて、リソース監視部２００は、イベント通知処理に進む（Ｓ５０６）。
【００４２】
同様に、リソース監視部２００は、アラーム情報管理テーブルにアラーム情報管理テーブル（ソケット用）２１６を指定する（Ｓ５０７）。続いて、リソース監視部２００は、イベント通知処理に進む（Ｓ５０８）。
【００４３】
全てのアラーム情報管理テーブルにイベント通知オブジェクト２０５が存在しない場合（Ｓ５０９でＹｅｓ）、リソース監視部２００は、図５に示す処理を終了する。アラーム情報管理テーブル２１３、２１４、２１５及び２１６にイベント通知オブジェクト２０５がひとつでも存在する場合（Ｓ５０９でＮｏ）、リソース監視部２００は、例えば１００ｍｓｅｃのウエイト処理を実行し（Ｓ５１０）、図５に示す処理の先頭に戻る。これによって、リソース監視システムは、ポーリングによってイベント通知オブジェクト２０５の有無を常に確認する。
【００４４】
図６は、実施形態１におけるリソース監視部２００によるイベント通知処理の一例を示すフローチャートである。
なお、イベント通知処理は、リソース監視部２００のリソース情報取得部２１１、アラーム情報取得部２１７、アラーム判定部２１０、イベント通知部２１２等によって実行される。
【００４５】
リソース監視部２００は、図５の処理で選択されたアラーム情報管理テーブルに、イベント通知オブジェクト２０５が存在する場合（Ｓ６０１でＹｅｓ）、Ｓ６０２に進む。Ｓ６０２におけるリソース情報取得処理については、図７で後述する。リソース監視部２００は、図５の処理で選択されたアラーム情報管理テーブルに、イベント通知オブジェクト２０５が存在しない場合（Ｓ６０１でＮｏ）、図５に示す処理を終了する。
【００４６】
Ｓ６０２の処理に続いて、アラーム情報取得部２１７は、アラーム情報管理テーブルからアラーム指定値２０４、イベント通知オブジェクト２０５及び状態フラグを取得する（Ｓ６０３）。
【００４７】
アラーム判定部２１０は、リソース現在値とアラーム指定値２０４との比較の結果、リソース現在値がアラーム指定値２０４を下回る（イコールも含む）と判定すると（Ｓ６０４でＹｅｓ）、Ｓ６０５に進む。アラーム判定部２１０は、リソース現在値とアラーム指定値２０４との比較の結果、リソース現在値がアラーム指定値２０４を上回ると判定すると（Ｓ６０４でＮｏ）、Ｓ６１０に進む。
【００４８】
Ｓ６０５において、アラーム判定部２１０は、取得した状態フラグが「ノーマル」か否かを判定する。取得した状態フラグが「ノーマル」の場合（Ｓ６０５でＹｅｓ）、リソース監視部２００は、Ｓ６０６に進む。取得した状態フラグが「ノーマル」でない場合（Ｓ６０５でＮｏ）、リソース監視部２００は、Ｓ６０９に進む。
【００４９】
Ｓ６０５の処理に続いて、リソース監視部２００（又はイベント通知部２１２）は、リソース現在値がアラーム指定値２０４を下回ったことを示す状態値ＡＬＲＡＭ＿ＩＮをイベントＩＤにセットしたイベントを生成する（Ｓ６０６）。
【００５０】
イベント通知部２１２は、イベント通知オブジェクト２０５に、Ｓ６０６において生成されたイベントを通知する（Ｓ６０７）。イベントを通知されたイベント通知オブジェクト２０５は、前記イベントをアプリケーション（Ａ）２０１に通知する。
【００５１】
リソース監視部２００は、前記状態フラグを「アラーム」に変更する（Ｓ６０８）。
【００５２】
リソース監視部２００は、次のイベント通知オブジェクト２０５がアラーム情報管理テーブルに存在する場合（Ｓ６０９でＹｅｓ）、Ｓ６０３で次のイベント通知オブジェクト２０５、アラーム指定値２０４及び状態フラグを取得する。そして、リソース監視部２００は、以降の処理を繰り返す。一方、リソース監視部２００は、次のイベント通知オブジェクト２０５がアラーム情報管理テーブルに存在しない場合（Ｓ６０９でＮｏ）、図６に示す処理を終了し、図５に示す処理に戻る。
【００５３】
Ｓ６０４でＮｏの場合、Ｓ６１０において、アラーム判定部２１０は、取得した状態フラグが「アラーム」か否かを判定する。取得した状態フラグが「アラーム」の場合（Ｓ６１０でＹｅｓ）、リソース監視部２００は、Ｓ６１１に進む。取得した状態フラグが「ノーマル」の場合（Ｓ６１０でＮｏ）、リソース監視部２００は、Ｓ６０９に進む。
【００５４】
Ｓ６１０の処理に続いて、リソース監視部２００（又はイベント通知部２１２）は、リソース現在値がアラーム指定値２０４を上回ったことを示す状態値ＡＬＡＲＭ＿ＥＸＩＴをイベントＩＤにセットしたイベントを生成する（Ｓ６１１）。
【００５５】
イベント通知部２１２は、イベント通知オブジェクト２０５にＳ６１１において生成されたイベントを通知する（Ｓ６１２）。イベントを通知されたイベント通知オブジェクト２０５は、前記イベントをアプリケーション（Ａ）２０１に通知する。
【００５６】
リソース監視部２００は、前記状態フラグを「ノーマル」に変更する（Ｓ６１３）。
【００５７】
以上の処理によって、アプリケーションプラットフォーム２０７の状態が、アラーム状態からノーマル状態、ノーマル状態からアラーム状態に遷移したとき、アプリケーションにイベントを通知することができる。
【００５８】
図７は、実施形態１におけるリソース情報取得部２１１の処理の一例を示すフローチャートである。リソース情報取得部２１１は、イベント通知処理で指定されたリソースのリソース現在値をアプリケーションプラットフォーム２０７から取得する部である。
【００５９】
リソース情報取得部２１１は、図５の処理で指定されたアラーム情報管理テーブルを取得する（Ｓ７０１）。指定されたアラーム情報管理テーブルがリソース監視テーブル（メモリ用）２１３である場合、リソース情報取得部２１１は、アプリケーションプラットフォーム２０７のメモリのリソース現在値を取得する（Ｓ７０２）。
【００６０】
指定されたアラーム情報管理テーブルがリソース監視テーブル（ディスク用）２１４である場合、リソース情報取得部２１１は、アプリケーションプラットフォーム２０７のディスク使用量のリソース現在値を取得する（Ｓ７０３）。
【００６１】
指定されたアラーム情報管理テーブルがリソース監視テーブル（ファイルディスクリプタ用）２１５である場合リソース情報取得部２１１はアプリケーションプラットフォーム２０７のファイルディスクリプタ同時使用量のリソース現在値を取得する（Ｓ７０４）。
【００６２】
指定されたアラーム情報管理テーブルがリソース監視テーブル（ソケット用）２１６である場合、リソース情報取得部２１１は、アプリケーションプラットフォーム２０７のソケット使用数のリソース現在値を取得する（Ｓ７０５）。
【００６３】
最後にリソース情報取得部２１１は、前記取得したリソースのリソース現在値をリターン値として返し、図７に示す処理を終了する。
【００６４】
図８は、実施形態１におけるアプリケーション（Ａ）２０１のリソース消費抑制処理の一例を示すフローチャートである。このリソース消費抑制処理によって、アプリケーション（Ａ）２０１はイベントを取得したときに、イベントのＩＤに応じて、任意の処理を切り替え、リソース消費量を抑えることができる。
【００６５】
アプリケーション（Ａ）２０１は、イベントからイベントＩＤを取得する（Ｓ１００１）。
【００６６】
アプリケーション（Ａ）２０１は、前記イベントＩＤがＡＬＡＲＭ＿ＩＮであった場合（Ｓ１００２でＡＬＡＲＭ＿ＩＮ）、アプリケーション（Ａ）２０１が実行している任意の処理を停止する（Ｓ１００３）。これによってアプリケーションプラットフォーム２０７のリソース消費量を減らし、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒを回避することができる。
【００６７】
アプリケーション（Ａ）２０１は、前記イベントＩＤがＡＬＡＲＭ＿ＥＸＩＴであった場合（Ｓ１００２でＡＬＡＲＭ＿ＥＸＩＴ）、停止していた任意の処理を開始する（Ｓ１００４）。これは、アプリケーションプラットフォーム２０７に任意の処理を実行するためのリソースが確保できた状態と判断したためである。
【００６８】
以上説明したように、実施形態１のリソース監視部２００によれば、アプリケーション（Ａ）２０１は、アラーム指定値２０４で指定したリソース量に、システムのリソース現在値が達したことを知ることができる。つまり、アプリケーション（Ａ）２０１は、アラーム指定値２０４に、アプリケーション（Ａ）２０１が利用するリソース消費量の上限値を指定することによって、ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を事前に察知することができる。
【００６９】
＜実施形態２＞
以下、本発明の実施形態２を、図９を参照しながら説明する。
図９は、実施形態２におけるイベント通知オブジェクト登録／削除処理の一例を示すフローチャートである。なお、イベント通知オブジェクト登録／削除処理は、イベント通知オブジェクト登録部２０８／イベント通知オブジェクト削除部２０９等によって実行される。本実施形態におけるイベント通知オブジェクト登録／削除処理は、実施形態１の図４に示したイベント通知オブジェクト登録処理を拡張したものである。拡張の概要としては、リソース監視部２００が同一のイベント通知オブジェクト２０５を取得した場合、対になるアラーム指定値２０４をリソース管理テーブルに再登録する（即ち上書き登録する）。また、リソース監視部２００がイベント通知オブジェクト２０５をリソース管理テーブルから削除する処理を追加したことである。
【００７０】
Ｓ８０１はＳ４０１と同じ処理である。同様にＳ８０２はＳ４０２、Ｓ８０３はＳ４０３、Ｓ８０４はＳ４０４、Ｓ８０５はＳ４０５、Ｓ８０６はＳ４０６、Ｓ８０８はＳ４０７、Ｓ８１１はＳ４０８と同一の処理である。
【００７１】
イベント通知オブジェクト２０５の「登録」を指定された場合（Ｓ８０７で登録）、イベント通知オブジェクト登録部２０８は、状態フラグを初期化する（Ｓ８０８）。続いて、イベント通知オブジェクト２０５がアラーム情報管理テーブルに登録されている場合（Ｓ８０９でＹｅｓ）、イベント通知オブジェクト登録部２０８は、Ｓ８１０に進む。イベント通知オブジェクト２０５がアラーム情報管理テーブルに登録されていない場合（Ｓ８０９でＮｏ）、イベント通知オブジェクト登録部２０８は、Ｓ８１１に進む。
【００７２】
Ｓ８１０において、イベント通知オブジェクト登録部２０８は、イベント通知オブジェクト２０５、アラーム指定値２０４及び状態フラグをアラーム情報管理テーブルに再登録する。また、Ｓ８１１において、イベント通知オブジェクト登録部２０８は、イベント通知オブジェクト２０５、アラーム指定値２０４及び状態フラグをアラーム情報管理テーブルに新規に登録する。
【００７３】
イベント通知オブジェクト２０５の「削除」を指定された場合（Ｓ８０７で削除）、リソース監視部２００は、Ｓ８１２に進む。Ｓ８１２において、イベント通知オブジェクト削除部２０９は、前記イベント通知オブジェクト２０５がアラーム情報管理テーブルに登録されているか否かを判定する。前記イベント通知オブジェクト２０５がアラーム情報管理テーブルに登録されている場合（Ｓ８１２でＹｅｓ）、イベント通知オブジェクト削除部２０９は、Ｓ８１３に進む。Ｓ８１３において、イベント通知オブジェクト削除部２０９は、イベント通知オブジェクト２０５、アラーム指定値２０４及び状態フラグをアラーム情報管理テーブルから削除する。前記イベント通知オブジェクト２０５がアラーム情報管理テーブルに登録されていない場合（Ｓ８１２でＮｏ）、リソース監視部２００は、図９に示す処理を終了し、上流の処理に戻る。
【００７４】
以上説明したように、実施形態２のリソース監視部２００によれば、アプリケーション（Ａ）２０１のアラーム指定値２０４を動的に変更することができる。これによって、同一のアプリケーションにおいて、処理内容の違いによってアラーム指定値が異なる場合、アラーム指定値を動的に変更し、柔軟にＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒの発生を監視することができる。
【００７５】
＜実施形態３＞
以下、本発明の実施形態３を、図１０を参照しながら説明する。
図１０は、実施形態３におけるリソース情報取得部２１１の処理の一例を示すフローチャートである。本実施形態におけるリソース情報取得処理は、実施形態１の図７に示したリソース情報取得処理を拡張したものである。拡張の概要を以下に説明する。
【００７６】
実施形態１の図７に示されたリソース取得処理では、例えばリソース情報取得部２１１が、リソース現在値を計算中に他のアプリがリソースを使用することによって、リソース現在値が変動するという問題があった。そこで、本実施形態におけるリソース情報取得部２１１は、リソース現在値を計算中は他のアプリケーションにメモリを確保させない処理を実行することによって、前記問題を解決する。
【００７７】
Ｓ９０１はＳ７０１と同様の処理である。また、Ｓ９０３はＳ７０３、Ｓ９０４はＳ７０４、Ｓ９０５はＳ７０５と同様の処理である
【００７８】
リソース情報取得部２１１は、メモリのリソース現在値を取得するとき、メモリ確保の機能をＯＦＦにする（Ｓ９０２）。これによってアプリケーションはメモリを確保することができない状態になる。リソース情報取得部２１１は、オブジェクトの参照関係を取得し、参照関係が残っているオブジェクトのメモリ残量を集計し、メモリのリソース現在値とする（Ｓ９０３）。続いて、メリソース情報取得部２１１は、モリ確保の機能をＯＮにする（Ｓ９０４）。これによってアプリケーションは通常どおりメモリを確保することが可能になる。
【００７９】
以上説明したように、実施形態３のリソース監視部２００によれば、リソース現在値を計算中はアプリケーションにメモリを確保させないようにすることができる。これによって、リソース情報取得部２１１は、呼び出された時点におけるリソース現在値を返すことが可能となる。
【００８０】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００８１】
本発明の目的は、上記実施形態の機能を実現するソフトウェア（プログラム）を記録した記憶媒体（記録媒体）をシステム又は装置に供給し、そのシステム又は装置のコンピュータ（ＣＰＵやＭＰＵ）が前記ソフトウェアを実行することでも達成される。この場合、記憶媒体から読み出されたソフトウェア自体が上記実施形態の機能を実現することになり、そのソフトウェアを記憶した記憶媒体は本発明を構成する。
【００８２】
また、前記ソフトウェアの実行により上記機能が実現されるだけでなく、そのソフトウェアの指示により、コンピュータ上で稼働するオペレーティングシステム（ＯＳ）等が実際の処理の一部又は全部を行い、それによって上記機能が実現される場合も含む。
【００８３】
また、前記ソフトウェアがコンピュータに接続された機能拡張カードやユニットのメモリに書き込まれ、そのソフトウェアの指示により、前記カードやユニットのＣＰＵ等が実際の処理の一部又は全部を行い、それによって上記機能が実現される場合も含む。
【００８４】
本発明を前記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャート（又はリソース監視方法）に対応するソフトウェアが格納される。
【図面の簡単な説明】
【００８５】
【図１】リソース監視システムのハードウェア構成を示すブロック図である。
【図２】リソース監視システム１００の機能構成を示すブロック図である。
【図３】実施形態１において、リソース監視部２００がイベント通知オブジェクトを登録するためのインタフェース・サービスを提供する処理の一例を示すフローチャートである。
【図４】実施形態１におけるリソース監視部２００のイベント通知オブジェクト登録部２０８による処理の一例を示すフローチャートである。
【図５】実施形態１において、リソース監視部２００がアプリケーションプラットフォーム２０７の状態を判定し、イベントを通知する処理の一例を示すフローチャートである。
【図６】実施形態１におけるリソース監視部２００によるイベント通知処理の一例を示すフローチャートである。
【図７】実施形態１におけるリソース情報取得部２１１の処理の一例を示すフローチャートである。
【図８】実施形態１におけるアプリケーション（Ａ）２０１のリソース消費抑制処理の一例を示すフローチャートである。
【図９】実施形態２におけるイベント通知オブジェクト登録／削除処理の一例を示すフローチャートである。
【図１０】実施形態３におけるリソース情報取得部２１１の処理の一例を示すフローチャートである。
【符号の説明】
【００８６】
２０１  アプリケーション（Ａ）
２０２  アプリケーション（Ｂ）
２０３  アプリケーション（Ｃ）
２０４  アラーム指定値
２０５  イベント通知オブジェクト
２０６  アプリケーション管理マネージャー
２０７  アプリケーションプラットフォーム
２０８  イベント通知オブジェクト登録部（イベント通知オブジェクト登録手段）
２０９  イベント通知オブジェクト削除部（イベント通知オブジェクト削除手段）
２１０  アラーム判定部（アラーム判定手段）
２１１  リソース情報取得部（リソース情報取得手段）
２１２  イベント通知部（イベント通知手段）
２１３  アラーム情報管理テーブル（メモリ用）
２１４  アラーム情報管理テーブル（ディスク用）
２１５  アラーム情報管理テーブル（ファイルディスクリプタ用）
２１６  アラーム情報管理テーブル（ソケット用）
２１７  アラーム情報取得部（アラーム情報取得手段）
【図１】
2008123211.tif 000003
【図２】
2008123211.tif 000004
【図３】
2008123211.tif 000005
【図４】
2008123211.tif 000006
【図５】
2008123211.tif 000007
【図６】
2008123211.tif 000008
【図７】
2008123211.tif 000009
【図８】
2008123211.tif 000010
【図９】
2008123211.tif 000011
【図１０】
2008123211.tif 000012