(57)【要約】【課題】メモリリークの発生を抑制しつつキャッシュデータの使用率が高いプロセスの利用継続を実現するシステムを提供すること。【解決手段】実行期間が定められた複数のプロセスを実行するシステム８０は、キャッシュデータの使用率に基づいて、第１のプロセスの実行期間を延長し、延長された第１のプロセスの実行期間に基づいて、第１のプロセス以外の第２のプロセスの実行期間を短縮し、実行期間が終了したプロセスを終了する。【選択図】  図１
2015141535.tif 000002
【特許請求の範囲】
【請求項１】
実行期間が定められた複数のプロセスを実行するシステムであって、
キャッシュデータの使用率に基づいて、第１のプロセスの実行期間を延長する延長手段と、
延長された前記第１のプロセスの実行期間に基づいて、前記第１のプロセス以外の第２のプロセスの実行期間を短縮する短縮手段と、
実行期間が終了したプロセスを終了する終了手段と、を備える
ことを特徴とするシステム。
【請求項２】
前記各プロセスの実行期間の経過に伴い増加するメモリリークを算出する算出手段をさらに備え、
前記短縮手段は、前記延長された第１のプロセスの実行期間におけるメモリリーク量が相殺されるように１または複数の前記第２のプロセスの実行期間を短縮する
ことを特徴とする請求項１に記載のシステム。
【請求項３】
前記短縮手段は、短縮された前記第２のプロセスの実行期間におけるメモリリーク量を算出し、算出されたメモリリーク量によって前記延長された第１のプロセスの実行期間におけるメモリリーク量が相殺されない場合に、別の前記第２のプロセスを選定し、実行期間を短縮する
ことを特徴とする請求項２に記載のシステム。
【請求項４】
前記短縮手段は、起動中であって、且つ、前記キャッシュデータの使用率が低い、または寿命が長い前記第２のプロセスの実行期間を短縮する
ことを特徴とする請求項１乃至３のいずれか一項に記載のシステム。
【請求項５】
前記短縮手段は、前記延長された第１のプロセスの実行期間に一致する期間を前記第２のプロセスの実行期間から短縮し、前記第２のプロセスの実行期間の終了時間が前記第１のプロセスの実行期間の終了時間よりも早い場合、前記第２のプロセスの終了時間から前記延長された第１のプロセスの実行期間の延長開始時間までの期間を前記第２のプロセスの実行期間から短縮する
ことを特徴とする請求項１乃至４のいずれか一項に記載のシステム。
【請求項６】
前記第２のプロセスの実行期間を短縮しても前記延長された第１のプロセスの実行期間におけるメモリリーク量が相殺されない場合に、短縮された全ての前記第２のプロセスの実行期間におけるメモリリーク量を算出し、算出されたメモリリークに基づいて前記第１のプロセスの実行期間の延長期間を決定する決定手段をさらに備える
ことを特徴とする請求項１乃至５のいずれか一項に記載のシステム。
【請求項７】
前記複数のプロセスによって、外部機器から要求されたデータ変換処理が行われる
ことを特徴とする請求項１乃至６のいずれか一項に記載のシステム。
【請求項８】
実行期間が定められた複数のプロセスを実行するシステムの制御方法であって、
キャッシュデータの使用率に基づいて、第１のプロセスの実行期間を延長する延長工程と、
延長された前記第１のプロセスの実行期間に基づいて、前記第１のプロセス以外の第２のプロセスの実行期間を短縮する短縮工程と、
実行期間が終了したプロセスを終了する終了工程と、を含む
ことを特徴とする制御方法。
【請求項９】
請求項８に記載の制御方法をコンピュータにより実行させることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上でＷｅｂサービスとして稼働するプログラムに関し、特に印刷装置に出力可能な形式にデータを変換するデータ変換サービスに関する。
【背景技術】
【０００２】
一般的に、Ｗｅｂサービスは高可用性が求められる。従って、Ｗｅｂサービスを構成するプログラムにメモリリークがあれば、長期に渡る稼働でＷｅｂサービスを提供するサーバ全体に影響を与えることになる。メモリリークに対する対策の一つとして、Ｗｅｂサービスを複数の機能コンポーネントに分割し、各々のコンポーネントを独立したプロセスとして動作させる方法が適用されている。機能コンポーネントは、その機能の複雑度やプログラムコードの量、処理内容における例外処理の発生頻度によってメモリリークの発生量に差があることが経験的に知られている。
【０００３】
例えば、特許文献１に開示されているシステムでは、サービスを提供する複数のプロセスの各々に再起動のタイミングを決定するカウンタを関連付けて、そのカウンタの値を単一の管理部が管理している。管理部は、処理のリスクに応じて各カウンタ値を更新し、閾値との比較により該プロセスの再起動を決定する。このシステムによれば、プロセスの再起動が順に実行され、従ってサービス提供中も順にメモリリークが解放される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−５４１１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本願のシステムでは前述のメモリリークの問題に着目しつつも、高スループットを実現する方法について検討する。データ変換処理における高スループットの確保のためにデータキャッシュを活用することを考える。キャッシュを用意、保持する為には初期投資としてのキャッシュデータ作成時間とある程度まとまったメモリ領域が必要となる。
【０００６】
例えばプリンタドライバと同様の機能を提供するＷｅｂサービスでは、印刷用のフォントデータのキャッシュなどが例として挙げられる。印刷ドキュメントにおけるフォントはページ毎に異なったりすることは少なく、少なくともあるドキュメントの中は同じフォントが指定されていることが考えられる。さらに、同一の利用者から作成される印刷ドキュメントは、同一のフォントを利用する傾向が高いものと想定する。従って、このように同一利用者から複数のドキュメントをＷｅｂサービスが受け取った結果、フォントデータのキャッシュが再使用されると、以降も異なる印刷ジョブに対して継続的にキャッシュの再使用が発生する可能性は高いと予想できる。
【０００７】
しかし、一方で前述のようにキャッシュを用意するとメモリ領域が必要となり、メモリ領域が必要になればメモリリークが発生する可能性が高まる。これに対して特許文献１のようにプロセスの再起動を行うと、前述のように今後もキャッシュを再使用する可能性の高いプロセスを再起動してしまいかねない。プロセスが再起動されれば用意したキャッシュは解放されてしまい、システムのスループット低下につながる。
【０００８】
本発明は、メモリリークの発生を抑制しつつキャッシュデータの使用率が高いプロセスの利用継続を実現するシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一実施形態の実行期間が定められた複数のプロセスを実行するシステムは、キャッシュデータの使用率に基づいて、第１のプロセスの実行期間を延長する延長手段と、延長された前記第１のプロセスの実行期間に基づいて、前記第１のプロセス以外の第２のプロセスの実行期間を短縮する短縮手段と、実行期間が終了したプロセスを終了する終了手段と、を備える。
【発明の効果】
【００１０】
本発明のシステムによれば、メモリリークの発生を抑制しつつキャッシュデータの使用率が高いプロセスの利用継続を実現することが可能となる。従って、システムの動作に安定性と高スループットを提供するパフォーマンス性の高いシステムを提供することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】一実施形態の印刷システムの全体構成例を示す図である。
【図２】サーバＰＣのハードウエア構成例を説明するブロック図である。
【図３】サーバＰＣのソフトウエア構成例を説明するブロック図である。
【図４】印刷データ変換部の動作に関連するコンポーネント群を説明する図である。
【図５】コンポーネントの生成、消滅、利用を説明する図である。
【図６】サービスカタログの構成を示す模式図である。
【図７】サービスインベントリの構成を示す模式図である。
【図８】コンポーネントの寿命処理を行うサーバＰＣの機能構成を示す図である。
【図９】実施例１の、ＰＤＬＦｉｌｔｅｒのイベントループの処理フローである。
【図１０】ＰＤＬＦｉｌｔｅｒの初期化処理の処理フローである。
【図１１】ＰＤＬＦｉｌｔｅｒの寿命延長確認処理の処理フローである。
【図１２】ＰＤＬＦｉｌｔｅｒの寿命延長処理の処理フローである。
【図１３】ロケータのイベントループの処理フローである。
【図１４】ロケータのメッセージ処理の処理フローである。
【図１５】ロケータの寿命延長処理の処理フローである。
【図１６】メモリリーク量の増加量と削減量の関係を示したグラフである。
【図１７】実施例２の、ＰＤＬＦｉｌｔｅｒのイベントループの処理フローである。
【図１８】ＰＤＬＦｉｌｔｅｒの寿命延長要求処理の処理フローである。
【図１９】ロケータのメッセージ処理の処理フローである。
【図２０】ロケータの寿命延長処理の処理フローである。
【発明を実施するための形態】
【００１２】
（実施例１）
図１は本発明の一実施形態の分散処理システムの構成例を示す図である。分散処理システムは、印刷変換サービスを要求する依頼者側の装置２０乃至４０、プリンタ６０、サービス提供側の装置７０乃至９０から構成される。印刷データの変換を依頼する依頼者５０は、印刷データの変換要求を送信する機器として、パーソナルコンピュータ２０、タブレットＰＣ３０、携帯端末４０などの機器を利用する。依頼者５０は、これらの機器の内部で動作しているアプリケーション（不図示）を用いて、ネットワーク１０上に存在する印刷データ変換部３３０（図３を参照して後述）に対して印刷データの変換を依頼する。
【００１３】
印刷データ変換部３３０は、サーバＰＣ８０上で周知のＵＲＬを公開している、いわゆるＷｅｂサービスとして動作しているプログラムである。サーバＰＣ８０上では、前記ＵＲＬに対して到着したパーソナルコンピュータ２０などの外部機器からの依頼を印刷データ変換部３３０に転送するＷｅｂ通信部３１０も動作している。ＵＲＬへ到着する依頼は通常多数になるため、単一のサーバＰＣ８０では処理させず、複数のサーバＰＣ８０に処理させる構成とする。従って、ロードバランサ７０が複数のサーバＰＣ８０の前段に設置され、各サーバＰＣ８０に転送される依頼が均一に配分される。
【００１４】
印刷データ変換部３３０が提供するサービスは、依頼者５０が指定するデータをプリンタ６０で印刷できる形式に変換することである。依頼者が指定するデータにはドキュメント、画像ファイルなど各種のアプリケーションプログラムで作成されたフォーマットが存在する。一方、プリンタ６０が印刷データとして受け付けるデータは前述のフォーマットとは異なり、ＰＤＬで記述されたデータや、印刷部数等の印刷を制御するための命令とパラメータを備えたＰＪＬで記述されたデータとなっている。ＰＪＬは、Ｐｒｉｎｔ  Ｊｏｂ  Ｌａｎｇｕａｇｅの略称である。
【００１５】
このように、依頼者５０とプリンタ６０の間には扱うデータ形式の差異が存在する為に、その差異を埋るプログラムが必要とされる。通常この変換処理を行うのがプリンタドライバと呼ばれるプログラムである。プリンタドライバは、依頼者５０が操作する前述のアプリケーションプログラムが動作しているＰＣ上で動作させることが通常である。しかし、プリンタドライバの処理は比較的ＣＰＵ、メモリなどのリソースを必要とする重い処理であるため、依頼者５０の操作するＰＣの保持するリソースが少ない場合には印刷処理が実用的でなくなる程時間のかかる処理になってしまう。依頼者５０が操作する端末（例えば、パーソナルコンピュータ２０、タブレットＰＣ３０、携帯端末４０）などリソースの比較的少ない端末からの印刷の需要が高まるにつれプリンタドライバの処理をインターネット上のサービスで行わせることの重要性が増している。
【００１６】
依頼者５０は、前述の各種端末から前述のＵＲＬに対して印刷データをプリンタ６０で印刷できる形式に変換するように依頼を行う。依頼に応じてサーバＰＣ８０上で動作している印刷データ変換部３３０が生成した変換後のデータは依頼元の端末に対して返送される。依頼者５０の指示によっては、変換後のデータは印刷データ変換部３３０がアクセス可能なファイルサーバＰＣ９０で保管される場合もある。
【００１７】
図２は、図１に示す各装置が備えるハードウエア構成例を示す図である。以下では、サーバＰＣ８０を例に説明する。サーバＰＣ８０は、ＨＤＤ１０２、ＲＯＭ１０３、ＲＡＭ１０４、ＣＰＵ１０５、出力装置１０６、入力装置１０７、通信装置１０８を備える。ＣＰＵ１０５は、サーバＰＣ８０の機能全体を統合的に制御する。また、ＣＰＵ１０５は、ＯＳ（オペレーティングシステム）とアプリケーションプログラムをＨＤＤ１０２またはＲＯＭ１０３から読み出してＲＡＭ１０４にロードし、実行することでプリントサービスの機能を実現する。ＣＰＵ１０５による処理結果はファイルとしてＨＤＤ１０２に格納、またはデータとしてＲＡＭ１０４に記憶される。なお、ＣＰＵ、ＨＤＤ、ＲＯＭ、ＲＡＭはそれぞれ、Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ、Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ、Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙの略称である。
【００１８】
ＨＤＤ１０２またはＲＯＭは、ＯＳ上で動作する図３に示すソフトウエア群を格納する。入力装置１０７は、使用者の入力や各種センサの読み取り値を取得する。出力装置１０６は、各種情報を出力し、処理結果を表示する。通信装置１０８は、ネットワークに接続された他のコンピュータや装置と通信を行う。これらのハードウエアはコントロールバス１００１で互いに接続されていて、アプリケーションプログラムから操作できるように構成されている。
【００１９】
図３は、本発明のシステムとして機能するサーバＰＣ８０のソフトウエア構成例を示す図である。サーバＰＣ８０は、Ｗｅｂ通信部３１０、アプリケーション部３２０、印刷データ変換部３３０、ロケータ３４０、ロガー３５０を備える。Ｗｅｂ通信部３１０は、依頼者５０が操作したパーソナルコンピュータ２０上のアプリケーションからＨＴＴＰプロトコルで送信されたリクエストを受け取る。ロードバランサ７０は、Ｗｅｂ通信部３１０の前段に位置し、複数のサーバＰＣ８０上で動作しているＷｅｂ通信部３１０に受信したリクエストを振り分ける。この振り分ける方式は種々知られているがその詳細は本発明には関係がないため説明を省略する。
【００２０】
ここで、サーバＰＣ８０は必ずしも物理的な一台のサーバＰＣを意味する必要はない。近年は、単一のＰＣ上に複数の仮想的なＰＣを出現させる仮想化技術が一般的となっており、ソフトウエアからみれば自身が動作しているオペレーティングシステムが仮想的に作り出されたものか否かは判別がつかないか、あるいは判別する必要がない。従って本発明におけるサーバＰＣ８０は「場合によっては仮想化されたＰＣ」を意味する場合もある。これ以降、「ＰＣ」という表現は物理的なＰＣと仮想化されたＰＣの両方を意味するものとして扱う。
【００２１】
アプリケーション部３２０は、要求の送付先として指定されたＵＲＬを解析し、関連付けられている印刷データ変換部３３０を決定するソフトウエアである。通常Ｗｅｂ通信部３１０とアプリケーション部３２０は複数種のサービスを扱うことが可能であり、ＵＲＬから対応するサービスを特定して要求を振り分けることができる。本実施例ではその複数種のサービスの一つが印刷データ変換部３３０であることを想定している。このサービスの他にもサービスが稼働しているが、発明の説明においては印刷データ変換部３３０以外のサービスは省略する。
【００２２】
印刷データ変換部３３０は、単一のプロセスではなく複数プロセスが共同して動作することでサービスを提供する形態をとっている。以下では「印刷データ変換サービス」という場合にはこれら複数のプロセスを総称していることに留意されたい。ロケータ３４０とロガー３５０は、印刷データ変換部３３０とは独立して存在するプロセスである。アプリケーション部３２０は、複数の要求を並列実行させるために印刷データ変換部３３０を複数起動し、各々に要求を振り分ける。この場合でも、ロケータ３４０とロガー３５０は各々一個のプロセスとして存在している。アプリケーション部３２０はさらに、印刷データ変換部３３０が動作する際に依頼者５０からの一連の要求を特定する為のセッションを管理する。具体的には、同一の依頼者５０からの要求は同一の印刷データ変換部３３０に転送するセッション・アフィニティーを実現している。
【００２３】
（印刷データ変換サービス）
図４は、印刷データ変換部３３０の動作に関連するソフトウエアコンポーネント群の関連を説明する図である。印刷データ変換部３３０は、先に説明したように複数のプロセスの共同体として動作している。その構成要素は印刷サービスゲートウェイ２１１、プロキシモジュール２２０、フィルタホスト２４０および各種フィルタ群（２７０，２８０，２９０）である。ここでは説明の為に各種フィルタは３種類示してあるが、実際には多くのフィルタが存在しており、さらにその組み合わせは固定化されておらず、生成される印刷データ変換部３３０毎に異なるフィルタが使用される可能性がある。
【００２４】
（印刷サービスゲートウェイ）
印刷データ変換部３３０に対するサービス依頼を受け付けるのは、プロセスとして存在する印刷サービスゲートウェイ２１１であり、その起動はアプリケーション部３２０が行う。印刷サービスゲートウェイ２１１はプロキシモジュール２２０をロードし、Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）で提供している関数群を呼び出すことで変換処理の実行を依頼し、さらに結果を受領する。プロキシモジュール２２０の提供するＡＰＩを呼び出して印刷データ変換部３３０にサービスの提供を依頼すると「ジョブ」と呼ばれるデータ構造が生成される。ジョブについての詳細な説明は後述する。
【００２５】
（ロケータ）
印刷データ変換部３３０を構成するコンポーネント群が利用するロケータ３４０は特別な役割を担っている。ロケータ３４０は、アプリケーション部３２０が起動した時点で既に起動している特殊なプロセスである。ロケータ３４０の起動の方法はサーバＰＣ８０上で動作しているオペレーティングシステム（ＯＳ）によって種々の方法が存在する。例えば、Ｗｉｎｄｏｗｓ（登録商標）であれば”Ｗｉｎｄｏｗｓ（登録商標）  Ｓｅｒｖｉｃｅ”というシステム起動時に自動的に起動される特殊なプロセスとして実装することが可能である。Ｌｉｎｕｘ（登録商標）やＵｎｉｘ（登録商標）ではデーモンプロセスとして動作させることが可能である。
【００２６】
ロケータ３４０は、コンポーネントを生成する機能を有する。さらに、ロケータ３４０は、他のコンポーネントからの求めに応じて別のコンポーネントのアクセスポイントを返すという機能を提供する。アクセスポイントとは、ＴＣＰ／ＩＰのリスンポートを指す。あるコンポーネントは、別のコンポーネントが公開しているアクセスポイントを取得し、そのアクセスポイントにアクセスすることでそのコンポーネントが提供する機能を利用する。あるコンポーネントが他のコンポーネントのアクセスポイントをロケータ３４０に対して問い合わせる動作を“ロケーションクエリ”あるいは単に“クエリ”と呼ぶ。
【００２７】
印刷データ変換部３３０を構成するコンポーネントのうち、プロキシモジュール２２０、ジョブコントローラ２３０、フィルタホスト２４０は、ロガー３５０が提供しているロギングデータをログファイルとして記録するサービスを利用している。そのため、ロケータ３４０に対してロガー３５０のアクセスポイントを得る目的でクエリを行っている。同様にプロキシモジュール２２０はジョブコントローラ２３０をクエリし、ジョブコントローラ２３０はフィルタＡ２７０、フィルタＢ２８０、フィルタＣ２９０をクエリする。クエリの詳細フローは後述する。
【００２８】
（ジョブコントローラ）
プロキシモジュール２２０を介してジョブ実行を依頼されたジョブコントローラ２３０は、ジョブ、およびジョブに含まれている印刷データを解析して変換に必要なフィルタを選定する。解析は印刷データの先頭から既定のサイズを読出しその中に含まれている特徴的な内容から印刷データの種類を判定する。例えば、ＪＰＥＧ形式や、ＰＤＦ形式のデータなどが入力データとして与えられる。次に、ジョブコントローラ２３０は、ジョブに含まれている変換先の印刷データ形式を取得し、変換元の印刷データ形式と変換先の印刷データ形式の両者が確定した時点で、この変換に必要なフィルタ群を選定する。必要なフィルタの組み合わせとその変換順番は固定的な知識としてジョブコントローラ２３０に実装されている。
【００２９】
必要な複数のフィルタを選定したあとに、ジョブコントローラ２３０はこれらフィルタをロードしているフィルタホスト２４０を取得する。この例では変換に必要なフィルタとして、フィルタＡ２７０、フィルタＢ２８０、フィルタＣ２９０が必要であり、それらはそれぞれフィルタホスト２４０にロードされている。
【００３０】
ジョブコントローラ２３０は、フィルタＡ２７０、フィルタＢ２８０、フィルタＣ２９０との間で、パイプライン３００と呼ばれるデータ転送チャネルを作成する。パイプライン３００は基本的に片方向にのみデータを転送する。ジョブコントローラ２３０→フィルタＡ２７０→フィルタＢ２８０→フィルタＣ２９０→ジョブコントローラ２３０と一周するようにパイプライン３００が構成される。また、ジョブコントローラ２３０はプロキシモジュール２２０との間にもパイプライン３００を作成する。このようにパイプライン３００を作成することで、プロキシモジュール２２０から印刷データが複数のコンポーネントを還流し、最後に変換が終了した形で再びプロキシモジュール２２０に戻ってくる。
【００３１】
（フィルタ、フィルタホスト）
フィルタは、データ変換処理のみを実装したライブラリモジュールの形式で用意されている。フィルタホスト２４０はプロセスとして存在し、実行時に指定されたフィルタをロードする。フィルタホスト２４０はコントロールバス５０２への接続とメッセージ送受信、パイプライン３００の生成と接続、ジョブコントローラ２３０との通信、フィルタのログ出力のロガー３５０への転送などの処理を担当する。
【００３２】
（ロガー）
ロガー３５０は、プロセスとして同一コントロールバス５０２上に一つ存在する。コントロールバス５０２上のコンポーネントは、ジョブの実行中にログ出力を行う。ログの出力対象としてはファイルが一般的であるが、すべてのコンポーネントが独立してログファイルの出力を行うとサーバＰＣ８０上のファイルＩ／Ｏの発生回数が増大し印刷データ変換部３３０全体のパフォーマンスが低下してしまう。そこで、各コンポーネントはログデータをロガー３５０に対してネットワークを介して送りつけ、ロガー３５０が一定量のログデータの蓄積時点でログファイルに出力することになっている。ログファイルの出力パス等の設定はロガー３５０が起動される際に渡されるコンフィギュレーションファイルで指定される。ここで、パイプライン３００を還流するデータについて説明する。このデータは「ジョブ」と呼ばれる。
【００３３】
（ジョブ）
データ変換処理は、プロキシモジュール２２０のＡＰＩを通じて依頼される際に、ジョブの形で引き渡される。ジョブは概念的には変換されるべき対象データと変換処理用の設定値などをまとまりのある形式に束ねた「チケット」と呼ばれるデータ構造から構成される。ジョブには、識別できるようにユニークな識別情報が与えられる（ジョブＩＤ）。生成されたジョブはファイルとしてＨＤＤ１０２などの記憶装置に格納される。また記憶装置から取り出す際にはジョブＩＤを指定してそのファイルを取得して内容を参照することが可能である。またジョブを破棄する行為はファイルの削除として実現される。ジョブはこの印刷データの内容を直接ファイル内に含むか、またはファイル化した印刷データのファイルパスなどの参照情報を含んでいる。さらにジョブは、印刷を行わせるプリンタ６０が処理できる印刷ファイル形式についての情報も含んでいる。さらに、印刷部数や印刷の面付指示などの印刷の処理方法を指定する印刷設定を含んでいる。以降では、ジョブを処理する行為を「ジョブを実行する」と呼ぶことがある。
【００３４】
（印刷データ）
プリンタが理解可能な形式で作成され、その内容をプリンタのメモリを介してハードウエアロジックに与えることが可能なバイナリ形式のデータを印刷データと称する。または、ファームウエアとして実装されている変換ロジックに与えて印刷エンジンが処理可能な形式に変換できる何らかの記述言語（ＰＤＬ）で記述されたデータを印刷データと称する。印刷データは、図１のパーソナルコンピュータ２０、タブレットＰＣ３０や携帯端末４０などの機器内に保持されているファイルから、またはメモリ内から変換要求に埋め込まれた形で取得される。あるいは、図１のファイルサーバＰＣ９０に予め格納されているファイルへの参照（ＵＲＬあるいはファイルパス）を変換要求から取り出してそのファイル内容を取得することにより印刷データは取得される。
【００３５】
ここで図４に立ち戻り、印刷データ変換部３３０を構成しているコンポーネント群が他のコンポーネントをクエリする意義と手順を説明する。
（クエリの意義）
コンポーネントが提供しているサービスは、ネットワークからアクセスできるエンドポイントとして他のコンポーネントに公開される。具体的には、ＴＣＰ／ＩＰのアドレスとポート番号の組が公開される。コンポーネントは他のコンポーネントの提供するサービスＩ／Ｆを取得して利用する。複数種類のコンポーネントがプロセスとして複数存在し、かつ同一コンポーネントも同一ＰＣ上に複数存在する。従って、各コンポーネントが公開するサービスＩ／Ｆのポート番号は固定にすることができず、自ずと動的に生成せざるを得なくなる。動的に生成されたエンドポイントは何らかの管理機構が無くては他から参照することはできない。このエンドポイントをロケータ３４０が管理する。さらに、コンポーネントが他のコンポーネントの動的に生成されたエンドポイントを取得する手段が必要である。この手段がクエリである。このクエリにロケータ３４０が回答する。
【００３６】
（コンポーネントの生成）
コンポーネントは基本的に動的に生成される。図５はコンポーネントの生成シーケンスを説明した図である。図５（Ａ）ではロケータ３４０のみが存在する状況である。この状況は図３においてサーバＰＣ８０が起動した直後に相当する。この時点ではまだ印刷データ変換部３３０は起動していない想定である。ロケータ３４０は単独でコントロールバス５０２に接続している状態である。
【００３７】
ロケータ３４０は、図６に示すサービスカタログ５０１を保持している。サービスカタログ５０１は、このサーバ８０上にインストールされているコンポーネントのリストから構成されている。コンポーネントごとに名前、バージョン、実行ファイルパス、起動時のコンフィギュレーションファイルパス、コンポーネントの寿命、起動モード、リーク量（リークレシオ）が記載されている。起動モードは、オンデマンドで起動するかホットスタンバイさせておくかを示すモードである。リーク量は、稼働に伴って発生する単位時間当たりのメモリリーク量である。コンポーネントの名前はその機能を表す一般的な名称が階層構造で表現される。例えば”ＦｉｌｔｅｒＨｏｓｔ”という機能名が”ｓｙｓｔｅｍ”という階層の下に定義されているため、“／ｓｙｓｔｅｍ／ＦｉｌｔｅｒＨｏｓｔ”という階層形式の表記となっている。この名前の表記方法は特に本発明の特徴とはなっていないがコンポーネントを組織的にかつユニークに命名する為に用いられている。同一の名前を持つコンポーネントであっても、そのバージョンが異なれば異なる機能を提供するためサービスカタログ５０１上では異なるエントリーとして扱われる。
【００３８】
図５（Ｂ）は、あるコンポーネントＡ５０３の起動モードがホットスタンバイ（ｓｔａｒｔｕｐ）に指定されている場合の例を示している。ロケータ３４０は、自身が起動したらこのサービスカタログ５０１を参照し、起動モードがホットスタンバイに指定されているコンポーネントＡ５０３を発見する。ロケータ３４０は、サービスカタログ５０１からコンフィギュレーションファイル５０５のパスと寿命を取得し、引数に与えてコンポーネントＡ５０３の実行ファイルパスのプログラムを起動させる。コンポーネントＡ５０３は、起動するとコントロールバス５０２に接続する時点でユニークなＩＤを与えられる。このＩＤは本実施例ではＧＵＩＤであるが他の形式でも構わない。起動モードにはそのほかにオンデマンド（ｏｎ−ｄｅｍａｎｄ）が定義されている。オンデマンドの起動モードを持つコンポーネントはそのシステム起動時には自動的には起動されず、文字通りそのコンポーネントを指定したクエリがなされて初めて起動される。
【００３９】
図５（Ｃ）は、起動したコンポーネントＡ５０３が、起動時に与えられたコンフィギュレーションファイル５０５の内容を参照して必要な初期値等を取り出し、さらにその初期値を使って自身を初期化する例を示す。初期化が完了するとサービスを提供する為に、ＴＣＰ／ＩＰのポートを取得しサービスＩ／Ｆ５０４の待ち受けを開始する。コンポーネントＡ５０３は、これで他のコンポーネントへのサービスの提供の準備ができたため、コントロールバス５０２に自身のアドバタイズメッセージ５０６を作成して送信する。
【００４０】
アドバタイズメッセージ５０６には、コンポーネントＡ５０３の名前、ＩＤ、バージョン、サービスＩ／Ｆ５０４のＵＲＬ、ポート番号、寿命が記載されている。このメッセージがロケータ３４０宛てに送信される。アドバタイズメッセージ５０６はコンポーネントが自身の起動完了とサービス提供開始を宣言する行為である。このメッセージを受信したロケータ３４０はコンポーネントＡ５０３の起動を確認し、かつサービスＩ／Ｆを取得することができる。
【００４１】
図５（Ｄ）は、ロケータ３４０がコンポーネントＡ５０３からのアドバタイズメッセージ５０６を受信した直後にコンポーネントＡ５０３の起動を確認し、以降の管理の為に管理テーブルであるサービスインベントリ５０７に登録を行った例を示す。
【００４２】
図８は、サービスインベントリ５０７の内容を模式的に表した図である。この例では、サービスインベントリ５０７は、ＩＤ、名前、バージョン、ＵＲＬ、Ｐｏｒｔ、寿命（時間）、寿命（ジョブ数）、生存時間、状態、起動時間、最終連絡時刻を備える。ロケータ３４０が、アドバタイズメッセージ５０６を受け取った時点でそのメッセージの送信元であるコンポーネント毎のエントリーを作成する。そして、ロケータ３４０が、アドバタイズメッセージ５０６の内容を転記してサービスインベントリに登録する。なお、エントリーの内容として、「生存時間」欄にはコンポーネントが作成されてからの生存時間（秒数）が記録される。この生存時間は後述するハートビートメッセージ５０８の内容から作成される。また「状態」欄にはコンポーネントの状態を示す値が後述するステートチェンジメッセージ５１２から転記される。「起動時刻」欄はコンポーネントが起動された時刻が、また「最終連絡時刻」欄はロケータ３４０がコンポーネントから最後に受け取ったメッセージの受け取り時刻を記録してある。本実施例では、時刻はオペレーティングシステムから取得されたシステム時刻で格納されている。通常、名前とバージョンが同一であるコンポーネントのプロセスは複数生成される。これらのサービスインベントリ５０７上のエントリーは少なくとも互いに、ＩＤとＰｏｒｔ番号が異なった値になるため識別が可能である。
【００４３】
図５（Ｅ）は、コンポーネントＡ５０３からハートビートメッセージ５０８を受け取った例を示す。ハートビートメッセージとは、自身が正常に稼動していることを外部に知らせるために送る信号やパケットである。各コンポーネントは定期的にハートビートメッセージ５０８をロケータ３４０宛てに送信しなければならない決まりとなっている。ロケータ３４０はこのメッセージを受け取ることにより送信元コンポーネントの生存を確認し、サービスインベントリ５０７の「生存時間」欄と「最終連絡時刻」欄を更新する。
【００４４】
もし、コンポーネントからのハートビートメッセージ５０８が既定時間滞ると、ロケータ３４０はこのコンポーネントの「状態」欄を「行方不明」に変更する。この状態でさらに既定時間ハートビートメッセージが滞ると、そのコンポーネントは自動的にサービスインベントリ５０７上からエントリーごと削除される。サービスインベントリ５０７上から削除されたコンポーネントはもはや他のコンポーネントからのクエリに対して検索されなくなり、サービスを提供できなくなる。エントリーの削除は対象コンポーネントのＩＤを基に行われるため、同一名称の他のコンポーネントのエントリーには影響は与えない。
【００４５】
図５（Ｆ）は、コンポーネントＡ５０３がコンポーネントＢ５１４を利用するために、ロケータ３４０に対してクエリメッセージ５０９を送信した例を示す。このクエリメッセージ５０９には、コンポーネントＢ５１４の名前と利用したいバージョンが記されている。コンポーネントは複数のバージョンが作成され得る。同一の名前のコンポーネントが機能の違いにより複数作成されて異なるバージョンとして市場にリリースされる。従ってコンポーネントＡ５０３はバージョン“２．０．０．１”の様に自分が利用したいコンポーネントＢ５１４のバージョンを指定してクエリを行うことができる。もし、特定バージョンを利用する必要が無いならばバージョン欄は空で指定することになっている。図５（Ｆ）に示す例では、コンポーネントＢ５１４はまだ生成されていない為、ロケータ３４０はコンポーネントＢ５１４を新たに生成する。図５（Ｂ）〜（Ｄ）に示したコンポーネントＡ５０３の生成手順と同じようにコンポーネントＢ５１４が生成される。
【００４６】
図５（Ｇ）は、ロケータ３４０がクエリに対するレスポンスをコンポーネントＡ５０３にクエリレスポンスメッセージ５１０として返却する例を示す。クエリレスポンスメッセージ５１０にはコンポーネントＢ５１４の名前、バージョン、サービスＩ／Ｆを示すＵＲＬとポート番号が格納されている。
【００４７】
図５（Ｈ）は、クエリレスポンスメッセージ５１０を受け取ったコンポーネントＡ５０３が、取得したコンポーネントＢ５１４のサービスＩ／Ｆを利用する様子である。コンポーネントによってはサービスＩ／Ｆにアクセスする他のサービスからのサービス要求を同時に扱えるものとそうでないものが存在する。例えば、ロガー３５０は、複数のサービスからのロギングデータを同時並行的に受け取りログファイルに記録していく能力を有する。一方、パイプラインを構成してジョブを変換するフィルタは、同時並行処理の能力をもたない。
【００４８】
従って、コンポーネントＢ５１４が同時並行処理能力を持たないコンポーネントであるとすると、コンポーネントＡ５０３がアクセスしてきた時点で他のコンポーネントからの要求を受け付けられない状態すなわちビジー状態に遷移する。この状態は、コンポーネントＡ５０３が明示的なアクセス終了をサービスＩ／Ｆを通じてコンポーネントＢ５１４に宣言するまで継続する。コンポーネントＢ５１４はビジー状態に遷移したら、自身を利用したいコンポーネントＡ以外の他のコンポーネントのクエリによって検出されないことが望ましい。
【００４９】
そこで、図５（Ｉ）に示すように、コンポーネントＢ５１４は、ステートチェンジメッセージ５１２をロケータ３４０に対して送信する。ステートチェンジメッセージ５１２には、コンポーネントＢ５１４がビジー状態に遷移したことが記されている。このメッセージを受け取ったロケータ３４０は、サービスインベントリ５０７に登録されたコンポーネントＢ５１４のエントリーを検索し、「状態」欄に受け取った状態を転記する。さらに「最終連絡時刻」欄も更新する。コンポーネントＢ５１４の「状態」欄がビジー状態に変更になった為、ロケータ３４０は以降、名前を指定したクエリを受け取ってもコンポーネントＢ５１４のインスタンスを選定することはなくなる。ただし、サービスインベントリ５０７には他のコンポーネントＢのプロセスが複数存在している可能性がある。それらのいずれかがビジー状態でなければ「利用可能なコンポーネントＢ」としてクエリの発行元のコンポーネントにレスポンスが返却される。
【００５０】
複数の同一名とバージョンを持ったコンポーネントインスタンス群からどのインスタンスをクエリの結果として選択するのかに関しては、ロケータ３４０が保持している選択アルゴリズムに依存している。しかし、そのアルゴリズムは本発明とは関係がない為説明を省略する。
【００５１】
図５（Ｊ）は、寿命に達したコンポーネントＢ５１４が自ら終了する直前にＧｏｏｄｂｙｅメッセージ（５１３）を送信した例を示す。このメッセージを受け取ったロケータ３４０は、サービスインベントリ５０７のコンポーネントＢ５１４のエントリーを削除する。
【００５２】
（寿命の延長処理）
次に、本発明の要点であるコンポーネントの寿命の操作に関する部分を説明する。図８は、コンポーネントの寿命管理に係る処理を行うサーバＰＣ８０の機能構成例を示す。サーバＰＣ８０は、フィルタ２４０（ＰＤＬＦｉｌｔｅｒ４５０、ＬａｙｏｕｔＦｉｌｔｅｒ４６０）、ロケータ３４０、ジョブコントローラ２３０を備える。これらは、印刷データ変換部３３０の処理を実行する主要なコンポーネントを抜き出したものである。ＰＤＬＦｉｌｔｅｒ４５０とＬａｙｏｕｔＦｉｌｔｅｒ４６０は図４のフィルタＡ２７０、フィルタＢ２８０、フィルタＣ２９０と同じフィルタコンポーネントであり、データ変換プロセスを担当する。
【００５３】
図８に示す例では、ＰＤＬＦｉｌｔｅｒ４５０は、フォントキャッシュ部１、キャッシュ統計部２、寿命延長判定部３、寿命管理部４を備える。フォントキャッシュ部１は、文字コードの変換処理でフォントキャッシュを検索し、所望の文字イメージが存在していたら利用する。キャッシュ統計部２は、フォントキャッシュ部１から指示を受け、文字種と文字コード別にキャッシュヒットの回数、ヒット率をジョブ単位に集計して記録する。寿命延長判定部３は、プロセスの実行期間の延長と延長する実行期間の長さを決定する。寿命管理部４は、ＰＤＬＦｉｌｔｅｒ４５０に設定された寿命を管理し、余命が一定の値に達すると、後述する「寿命イベント」を生成する。また、ロケータから寿命設定値を取得し、その設定値を自身の新寿命として再設定する。
【００５４】
ロケータ３４０は、プロセス管理部５、リーク管理部６、サービスカタログ５０１、サービスインベントリ５０７を備える。プロセス管理部５は、各プロセスからメッセージを受信し、メッセージの内容に応じて各種処理を実行する。例えば、プロセス管理部５は、フィルタ２４０から後述する寿命延長メッセージを取得し、図１４，図１５を用いて後述する寿命延長処理を実行する。リーク管理部６は、あるプロセスの寿命が延長される際に、現在稼働しているプロセスのなかから寿命を短縮すべきものを選定する。そして、選定したプロセスに対し、負の値を記した寿命変更メッセージを送信する。また、ジョブコントローラ２３０、ＬａｙｏｕｔＦｉｌｔｅｒ４６０は、自身の寿命を管理する寿命管理部７，８を備える。寿命管理部７，８は、リーク管理部６から寿命短縮の指示を受けると、自身に設定された寿命の値を指定された値で再設定する。
【００５５】
以下の説明では、寿命を延長してほしいコンポーネントとしてＰＤＬＦｉｌｔｅｒ４５０を、寿命を短縮されるコンポーネントとしてＬａｙｏｕｔＦｉｌｔｅｒ４６０とジョブコントローラ２３０を選定したものとする。また、ロケータ３４０が寿命を短縮するコンポーネントを選定する。ＰＤＬＦｉｌｔｅｒ４５０の動作をフローチャートを用いて説明し、寿命の延長を宣言する処理を明らかにする。その後、宣言を受けたロケータ３４０が寿命を短縮させるコンポーネントを選定する処理を説明し、最後に寿命を短縮されるコンポーネントの処理を説明する。サーバＰＣ８０のＣＰＵ１０５は、ＨＤＤ１０２またはＲＯＭ１０３に記憶したプログラムをＲＡＭ１０４にロードし実行することにより図３や図８に示す各機能を実行する。
【００５６】
（ＰＤＬＦｉｌｔｅｒの処理フロー）
最初にＰＤＬＦｉｌｔｅｒ４５０の処理フローについて説明する。図９は、ＰＤＬＦｉｌｔｅｒ４５０がフィルタホスト２４０にロードされて起動した時点から開始するイベントループ処理（Ｓ００１）である。コンポーネントは、起動した時点でメッセージキューを備えている。コンポーネントは、外部コンポーネントとの通信手段であるコントロールバス５０２からメッセージを受信した時点でメッセージに対応するイベントを作成し、メッセージキューに投函する。コンポーネントは、そのほかにも内部のモジュールからの通知もイベントとして作成し投函する。
【００５７】
ＰＤＬＦｉｌｔｅｒ４５０は、起動した直後に、図１０に示す初期化処理（Ｓ１００）を実行する。初期化処理（Ｓ１００）は、各種の初期設定を行う処理の集合である。
【００５８】
図１０は、Ｓ１００の初期化処理を説明するフローチャートである。Ｓ１０１では、ＰＤＬＦｉｌｔｅｒ４５０は、起動時に渡されたコンフィギュレーションファイルの内容を解析して必要な動作パラメータを取得する。取得した動作パラメータの一つに「寿命」がある。Ｓ１０２では、ＰＤＬＦｉｌｔｅｒ４５０は、寿命管理部４に取得した寿命を設定する。寿命は秒単位で表現した値である。ＰＤＬＦｉｌｔｅｒ４５０は、機能として図８には図示していないパイプライン３００を流れるジョブ中から文字種、文字コードを取り出し、対応する文字イメージを作成して印刷データに格納する処理を担当している。一度作成した文字イメージは削除せずキャッシュ領域に保存しておく。Ｓ１０３ではその領域の初期化が行われる。
【００５９】
図９に戻り、初期化処理が終了した後、処理はＳ００２に進む。Ｓ００２以降の処理では、ＰＤＬＦｉｌｔｅｒ４５０は２つのイベントを待ち受けながら終了するまで無限にループする。待ち受けるイベントは「ジョブ実行要求」と「寿命」である。まず、Ｓ００２で、ＰＤＬＦｉｌｔｅｒ４５０は、ジョブコントローラ２３０から受け付けたイベントが「実行要求」か否かを判断する。このジョブ実行要求は、フィルタが作成したサービスＩ／Ｆ５０４に対してジョブコントローラ２３０が送信してきたジョブ実行要求に対応して作成されるイベントである。Ｓ００２で「ジョブ実行要求」を検出すると、ＰＤＬＦｉｌｔｅｒ４５０はＳ２００のジョブ実行処理を実行する。ジョブ実行は新たにスレッドが作成されてそのスレッド上で処理が進むため、イベントループ処理（Ｓ００１）と並行に処理が進む。ジョブ実行処理はステート管理される為、ジョブ処理中に新たなジョブ実行要求イベントが到着してもその要求は拒否される。ジョブの実行処理はジョブコントローラ２３０が作成した印刷データの通路であるパイプライン３００を還流するジョブの内容を検査し、含まれている文字種と文字コードを文字イメージに変換する処理である。
【００６０】
ジョブ実行処理では、ＰＤＬＦｉｌｔｅｒ４５０は文字コードの変換において、まず図８のフォントキャッシュ部１を検索し、所望の文字イメージが存在していたら利用する。また、ＰＤＬＦｉｌｔｅｒ４５０は、キャッシュ統計部２に文字種と文字コード別にキャッシュヒットの回数、ヒット率をジョブ単位に集計して、キャッシュ統計情報として記録する。
【００６１】
Ｓ００２において、ジョブ実行要求ではない場合、処理はＳ００３に進む。Ｓ００３では、ＰＤＬＦｉｌｔｅｒ４５０は、「寿命イベント」か否かを判断する。寿命イベントは、寿命管理部４から発行されるイベントである。寿命管理部４では、起動時に指定された寿命が刻々と減算されている。寿命管理部４は、余命が一定の値に達したらプロセスの停止処理を開始するように「寿命イベント」を生成して投函する。
【００６２】
Ｓ００３において、ＰＤＬＦｉｌｔｅｒ４５０が寿命イベントと判断した場合、Ｓ３００に処理は進む。Ｓ３００の詳細は図１１を用いて後述する。Ｓ３００の処理後、処理はＳ００４に進み、ＰＤＬＦｉｌｔｅｒ４５０は寿命を延長するか否かを判断する。寿命を延長しない場合、処理はＳ５００に進み、ＰＤＬＦｉｌｔｅｒ４５０は処理を終了する。寿命を延長する場合、処理はＳ４００に進み、ＰＤＬＦｉｌｔｅｒ４５０は寿命延長処理を実行する。寿命延長処理の詳細は図１２を用いて後述する。
【００６３】
図１１は、寿命延長確認処理を説明するフローチャートである。Ｓ００３で寿命イベントを検出すると、寿命延長判定部３がＳ３００の寿命延長確認処理を実行する。Ｓ３０１では、寿命延長判定部３は、寿命イベントを検出した時点でジョブ実行処理中か否かを判断する。実行中の場合は寿命イベントの受信が記憶されるのみでジョブの実行が終了するまで処理が中断される。
【００６４】
Ｓ３０２において、寿命延長判定部３は、キャッシュ統計部２が保持している直近のジョブにおけるキャッシュデータのヒット率（使用率）から将来のジョブにおけるヒット率を予想する。この予想には、印刷データ変換部３３０に特有の評価方法をとることができる。例えば、直近の３ジョブのヒット率の平均を算出し、さらに直近のジョブのヒット率に重みを付けて加算するなどの評価方法が採用できる。Ｓ３０３において、予想値が既定以上になる場合には、寿命延長判定部３はプロセスの寿命延長と延長する寿命の長さを決定する。
【００６５】
図１２は、寿命延長処理を説明するフローチャートである。Ｓ４００では、寿命延長判定部３が判定した寿命延長結果を検査する。寿命延長が決定されない場合には、Ｓ５００の終了処理が実行されてプロセスが終了する。終了処理では、処理中に作成したリソース、メモリの解放が行われる。寿命延長が決定された場合には、Ｓ４００の寿命延長処理が実行される。Ｓ４０１では、寿命延長判定部３は、決定された延長する寿命の長さ（延長量）と現在時刻から寿命管理部４に設定する設定値を計算して設定する。続いて、Ｓ４０２では、寿命延長判定部３は、延長する寿命の長さを含めた寿命延長メッセージ５１５を作成してロケータ３４０に送信し、処理を終える。
【００６６】
（ロケータの処理フロー）
Ｓ４０２の通知を受けたロケータ３４０が行う処理フローについて説明する。図１３は、ロケータ３４０が起動した時点から開始するイベントループ処理（Ｓ１００１）である。ロケータ３４０もコンポーネントであるため、メッセージキューを保持している。他のコンポーネントと異なり、ロケータ３４０はサービスＩ／Ｆを提供せず、他のコンポーネントとのコントロールバス５０２を経由したメッセージ交換がプロセスの外部との通信手段である。その際の受信で発生するイベントと、内部のモジュールからの通知がイベントとして作成され、先のメッセージキューへ投函される。
【００６７】
ロケータ３４０は、起動した直後に初期化処理（Ｓ１１００）を実行する。初期化処理は、各種の初期設定を行う処理の集合である。Ｓ１１０１では、ロケータ３４０は、起動時に渡されたコンフィギュレーションファイルの内容を解析して必要な動作パラメータを取得する。初期化処理には、既に説明したように、サービスカタログ５０１を参照し、起動モードが「ホットスタンバイ（ｓｔａｒｔｕｐ）」に指定されているコンポーネントを生成する処理も含まれる。ロガー３５０もホットスタンバイに指定されているためこの時点で生成される。Ｓ１１００の初期化処理が終了すると、処理はメッセージ処理（Ｓ１００２）に進む。
【００６８】
図１４は、メッセージ処理（Ｓ１００２）を説明するフローチャートである。処理されるメッセージは、既に説明したアドバタイズメッセージ５０６、ハートビートメッセージ５０８、クエリメッセージ５０９、ステートチェンジメッセージ５１２、Ｇｏｏｄｂｙｅメッセージ５１３と寿命延長メッセージ５１５である。Ｓ１００３では、ロケータ３４０は、受信したメッセージが寿命延長メッセージ５１５か否かが判断される。寿命延長メッセージの場合、処理はＳ１００４に進み、寿命延長処理が実行される。その他のメッセージもＳ１００５に示すような判断およびＹｅｓと判断された場合の処理が関連つけられてメッセージの数だけ用意されている。寿命延長メッセージ５１５以外のメッセージは既に説明済みであるため、ここでの説明は省略する。
【００６９】
図１５は、寿命延長処理を説明するフローチャートである。寿命延長メッセージ５１５はプロセス管理部５が処理する。Ｓ１１００では、プロセス管理部５は、メッセージに含まれている送信元のノードＩＤからサービスインベントリ５０７を参照して、寿命延長メッセージ５１５の送信元を特定する。ここでは、ＰＤＬＦｉｌｔｅｒ４５０であると特定される。
【００７０】
Ｓ１１０１では、プロセス管理部５は、サービスインベントリ５０７内のＰＤＬＦｉｌｔｅｒ４５０の寿命を寿命延長メッセージ５１５に記載の延長量を加えた値に置換する。続いて、Ｓ１１０２では、プロセス管理部５は、現在の推定リーク量を更新するとともに、サービスカタログ５０１のリークレシオと寿命の延長分から、寿命延長に伴って増加するリーク増分を計算する。計算されたリーク増分はリーク管理部６に対して入力される。
【００７１】
Ｓ１００３で、リーク管理部６は、延長されたＰＤＬＦｉｌｔｅｒ４５０の実行期間に応じてこのプロセス以外のプロセスを選定する。具体的には、リーク管理部６は、入力されたリーク増分に基づいて、起動中のプロセスの中から寿命を短縮すべきプロセスを選定する。選定にあたってはリークレシオが高いものから優先的に選定する方法や寿命が長いものから優先的に選定する方法など種々考えられるがいずれの方法でも構わない。リーク管理部６は、ＰＤＬＦｉｌｔｅｒ４５０の延長された寿命に伴い増加するリーク量を計算する。そして、リーク管理部６は、選択したプロセスの寿命をＰＤＬＦｉｌｔｅｒ４５０が延長開始する時点までに短縮するものとして減少するリーク量を計算する（計算方法は後述する）。
【００７２】
Ｓ１１０４では、リーク管理部６は、選定したプロセスに対して寿命変更メッセージ５１６を送信する。Ｓ１００５では、リーク管理部６は、寿命延長に伴うリーク増加量からＳ１１０４で計算した寿命短縮によるリーク減少量を減じ、まだ零あるいは負値になっていないか（つまりは相殺が完了したか）を判断する。ここでリーク増加量及びリーク減少量は後述するように、主にプロセスの実行期間によって決定される。相殺していないと判断された場合、処理はＳ１１０３に戻り、リーク管理部６は他の実行中プロセスのなかから別ものものを選定する。Ｓ１１０５では、リーク管理部６は選定すべきプロセスが存在しない場合には処理を終了する。
【００７３】
図８では寿命短縮の対象としてジョブコントローラ２３０とＬａｙｏｕｔＦｉｌｔｅｒ４６０の２つのコンポーネントが選定されたものとしている。リーク管理部６は、ジョブコントローラ２３０とＬａｙｏｕｔＦｉｌｔｅｒ４６０の双方に対して負の値を記した寿命変更メッセージ５１６を送信する。このメッセージには現在設定されている寿命からの変化分が記載されている。変化分が「２０」となっていれば２０秒の寿命延長を意味し、「−３０」と負の値であれば、３０秒の寿命短縮を意味する。
【００７４】
（寿命を短縮されるコンポーネントの処理）
ロケータ３４０が選定したジョブコントローラ２３０とＬａｙｏｕｔＦｉｌｔｅｒ４６０に対して、其々の寿命の短縮量が計算されて寿命変更メッセージ５１６が送信される。ジョブコントローラ２３０とＬａｙｏｕｔＦｉｌｔｅｒ４６０は、寿命管理部７，８に対し寿命変更メッセージ５１６を引き渡す。各寿命管理部７，８はメッセージから寿命設定値を取得し、その設定値を自身の新寿命として設定する。
【００７５】
（リーク増加分の相殺計算）
図１６を参照し、リーク量の算出を具体的に説明する。図１６は、（１）ＰＤＬＦｉｌｔｅｒ４５０、（２）ジョブコントローラ２３０、（３）ＬａｙｏｕｔＦｉｌｔｅｒ４６０の３つのコンポーネントの時間とメモリ使用量の関係を示す。図１６（１）のｔ１はＰＤＬＦｉｌｔｅｒ４５０が起動した時刻を意味する。
【００７６】
ｔ１の時点では起動しただけで、ジョブを処理しておらずメモリ使用量はコンポーネントが動作上で必要としているメモリだけが確保されている。時刻ｔ２でＰＤＬＦｉｌｔｅｒ４５０はジョブを処理開始した。ジョブ処理に応じて必要なメモリが確保されて使用されるがプログラム上の不具合によって利用されたメモリの解放が行われずメモリリークが発生することになる。従って、ｔ２から時間の経過とともにリークが蓄積していくためメモリ使用量は単調増加の様態を示す。その際の直線の傾きは図７に示すサービスカタログ５０１のリークレシオに記載された値に応じて異なる。
【００７７】
ここでＰＤＬＦｉｌｔｅｒ４５０に当初設定された寿命（生存期間）は（ｔ３−ｔ１）である。すなわちｔ３の時点でプロセスを終了したならばメモリ使用量は０に戻る。先に説明したように、ＰＤＬＦｉｌｔｅｒ４５０が自らの終了時刻をｔ３からｔ４に変更（延長）した場合には、その延長に伴って増加したメモリリークの総量はΔＳ（Ｂ）で表わされる。この部分はＰＣ上で他に転用できなかった無駄なメモリの総量を意味する。厳密にはｔ１とｔ２は異なるが、ΔＳ（Ｂ）の計算上ｔ２はｔ１とみなして差支えない。従って、リークレシオをｋとすると、ΔＳ（Ｂ）は以下の式により計算される。
ΔＳ（Ｂ）＝１／２・ｋ・｛（ｔ３−ｔ１）＋（ｔ４−ｔ１）｝・（ｔ４−ｔ３）
ここで、ｋはサービスカタログ５０１の「リークレシオ」、ｔ１はサービスインベントリ５０７の「起動時刻」、ｔ３はｔ１にサービスインベントリ５０７の「寿命（時間）」を加えた値から得られる。また、（ｔ４−ｔ３）は、ＰＤＬＦｉｌｔｅｒ４５０が送信した寿命変更メッセージ５１６の「変化分」から得られる。
【００７８】
同様に図１６（２）と図１６（３）は、それぞれあるジョブコントローラ２３０を担当するプロセスのメモリ使用量の計時変化と、ＬａｙｏｕｔＦｉｌｔｅｒ４６０を担当するプロセスのメモリ使用量の計時変化である。ジョブコントローラ２３０（２）のプロセスは時刻ｔ５で起動し、時刻ｔ６でジョブ処理を開始し、時刻ｔ７で終了する予定であるとする。ここでは、ジョブコントローラ２３０の終了時間はＰＤＬＦｉｌｔｅｒ４５０の終了時間よりも早い。従って、時刻ｔ７で終了する予定であったジョブコントローラ２３０を時刻ｔ３（延長されたＰＤＬＦｉｌｔｅｒ４５０の延長開始時間）で終了させると仮定するとΔＳ（Ｊ）部分のメモリ量がリークする予定から０に削減されることになる。ここでも、リークレシオをｈとすると、ΔＳ（Ｊ）は以下の式により計算される。
ΔＳ（Ｊ）＝１／２・ｈ・｛（ｔ３−ｔ５）＋（ｔ７−ｔ５）｝・（ｔ７−ｔ３）
【００７９】
また、ＬａｙｏｕｔＦｉｌｔｅｒ４６０プロセスは時刻ｔ１０で終了する予定のところ、延長されたｔ３からｔ４までの期間に一致する期間の寿命を短縮すると仮定すると、リークレシオをｇとするならば、ΔＳ（Ｌ）は以下の式により計算される。
ΔＳ（Ｌ）＝１／２・ｇ・｛（ｔ３−ｔ８）＋（ｔ４−ｔ８）｝・（ｔ４−ｔ３）
従って、現在実行中のコンポーネントの中から以下の式を満たすプロセスが選定される。
ΔＳ（Ｂ）＜＝ΔＳ（Ｊ）＋ΔＳ（Ｌ）
リーク管理部６は、選定したプロセスに対し、寿命を短縮するように制御する。
【００８０】
以上、本発明のシステムによれば、メモリリークの発生を抑制しつつキャッシュデータの使用率が高いプロセスの利用継続を実現することが可能となる。具体的には、実施例１では、寿命が間近に迫ったコンポーネントが自身の寿命の延長が有効と判断したらその延長をロケータ３４０に通知する。ロケータ３４０はリーク増加分を相殺する目的で適当なコンポーネントを選定してその寿命を短縮させることができる。
【００８１】
（実施例２）
実施例１では、寿命の延長を望むコンポーネントは自分で延長を決定し、その決定をロケータ３４０に寿命延長メッセージ５１５として送信することで延長が確定していた。寿命延長メッセージ５１５を受け取ったロケータ３４０は、寿命延長にともなって増加するリーク量を相殺すべく他のコンポーネントに対して寿命の短縮を命じる。このシステムでは、延長の決定と延長量には他のコンポーネントの状況が反映されていないため、場合によっては相殺に利用できるコンポーネントが不足する場合がある。その場合には、システムはリークが増加することになる。
【００８２】
実施例２では、寿命の延長を望むコンポーネントは延長の必要性と延長期間は算出するものの、ロケータ３４０に対して延長要求として送信し、その応答に含まれる延長の是非、延長量に従って寿命延長を実行する。ロケータ３４０は、寿命延長メッセージを受信した時点で実行中のコンポーネントの検索を行い、寿命短縮可能なコンポーネントを確定させたうえで寿命延長に応答する。この実施例によれば処理効率よりも、システム全体のリーク量を制限したい要求にこたえることが可能になる。
【００８３】
図１７は、実施例２におけるＰＤＬＦｉｌｔｅｒ４５０がフィルタホスト２４０にロードされて起動した時点から開始するイベントループ処理（Ｓ００５）である。実施例１におけるイベントループ処理（Ｓ００１）に比べてＳ００６の判断、およびその後の処理が追加されている。さらに、Ｓ４００の寿命延長処理がＳ４１０の寿命延長要求処理に変更されている。以下、変更点についてのみ説明を行う。変更のない処理ステップについての説明は実施例１と同一の説明が適用できる。
【００８４】
Ｓ１００の初期化処理が終了したあとはＳ００２、Ｓ００６、Ｓ００３において各々イベントの到着を待ってループしている。寿命管理部４は寿命が近づいたため「寿命イベント」をＰＤＬＦｉｌｔｅｒ４５０に対して投函する。Ｓ００３で、ＰＤＬＦｉｌｔｅｒ４５０は「寿命イベント」を検出する。その後Ｓ３００の寿命延長確認処理が実行され寿命延長の必要性と延長量が計算される。Ｓ５３００では、ＰＤＬＦｉｌｔｅｒ４５０は寿命延長確認処理を実行する。Ｓ５３００の結果が検査されて、延長が必要である場合には図１８のＳ４１０の寿命延長要求処理が実行される。図１８に示すように、Ｓ４１１において、寿命延長判定部は、寿命延長メッセージ５１５を作成しロケータ３４０に対して送信する。
【００８５】
この後、ＰＤＬＦｉｌｔｅｒ４５０はロケータ３４０からの「寿命延長レスポンスメッセージ」の到着を待つ。Ｓ００６では、ＰＤＬＦｉｌｔｅｒ４５０は寿命延長メッセージを検出する。Ｓ００７では、ＰＤＬＦｉｌｔｅｒ４５０はメッセージの内容を解析する。メッセージ内の結果が寿命延長を決定した旨が記載されている場合には、処理はＳ４２０に進む。Ｓ４２０では、ＰＤＬＦｉｌｔｅｒ４５０は、レスポンスメッセージに記載されている寿命延長量を取得して寿命管理部４に設定する。この時点で新寿命が確定しＰＤＬＦｉｌｔｅｒ４５０は寿命が延長される。Ｓ００７においてメッセージに寿命延長が拒否された旨が記載されている場合には、Ｓ５００に処理が進み、ＰＤＬＦｉｌｔｅｒ４５０はプロセスを終了する。
【００８６】
図１９は、ロケータ３４０のメッセージ処理を説明するフローチャートである。実施例１と比較して寿命延長処理（Ｓ１００６）が変更になっている。Ｓ１００３では、ロケータ３４０は寿命延長メッセージ５１５を受信し、Ｓ１００６に処理が進む。
【００８７】
図２０は、寿命延長処理（Ｓ１００６）の詳細を説明するフローチャートである。Ｓ１１００において、プロセス管理部５は、メッセージに含まれている送信元のノードＩＤからサービスインベントリ５０７を参照して寿命延長メッセージ５１５の送信元を特定する。ここでは、プロセス管理部５は、ＰＤＬＦｉｌｔｅｒ４５０であると特定する。続いてサービスカタログ５０１のリークレシオと寿命の延長分から寿命延長に伴って増加するリーク増分を計算する（Ｓ１１０２）。計算されたリーク増分はリーク管理部６に対する入力となる。
【００８８】
Ｓ１００３では、リーク管理部６は、現在稼働しているプロセスの中から寿命を短縮すべきプロセスを選定する。リーク管理部６は、リーク管理部６は、ＰＤＬＦｉｌｔｅｒ４５０の延長された寿命に伴い増加するリーク量を計算する。そして、リーク管理部６は、選択したプロセスの寿命をＰＤＬＦｉｌｔｅｒ４５０が延長開始する時点までに短縮するものとして減少するリーク量を計算する。
【００８９】
Ｓ１１０４では、リーク管理部６は、選定したプロセスに対して寿命変更メッセージ５１６を送信する。Ｓ１００５では、リーク管理部６は、寿命延長に伴うリーク増加量からＳ１１０４で計算した寿命短縮によるリーク減少量を減じ、まだ零あるいは負値になっていないか（つまりは相殺が完了したか）を判断する。相殺がしていないと判断された場合、処理はＳ１１０３に戻り、リーク管理部６は、他の実行中プロセスのなかから別ものプロセスを選定する。
【００９０】
Ｓ１１０５において、寿命短縮対象の実行プロセスが尽きてしまった場合にもループを抜け、処理はＳ１１０１に進む。この時点で寿命短縮対象として選定されたプロセスのリーク削減量が確定する。プロセス管理部５は、この削減量に基づいてＰＤＬＦｉｌｔｅｒ４５０の寿命延長量を算出する。
【００９１】
プロセス管理部５は、サービスインベントリ５０７内のＰＤＬＦｉｌｔｅｒ４５０の寿命を算出された延長量を加えた値に置換する（Ｓ１１０１）。Ｓ１１０６において、プロセス管理部５は、算出された寿命延長量を記載したレスポンスメッセージを作成し、ＰＤＬＦｉｌｔｅｒ４５０に送信し、処理を終了する。この処理フローから理解できるように、本実施例では実施例１と異なり、寿命短縮対象となるコンポーネントの選定が先に実施され、その後、確定した削減量に応じて寿命延長を望むコンポーネントの延長期間が確定することになる。この実施例では、システムのリーク増加を抑制することが効率よりも重視された印刷データ変換サービスが提供されることになる。
【００９２】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウエア（コンピュータプログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そしてそのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。
【図１】
2015141535.tif 000003
【図２】
2015141535.tif 000004
【図３】
2015141535.tif 000005
【図４】
2015141535.tif 000006
【図５】
2015141535.tif 000007
【図６】
2015141535.tif 000008
【図７】
2015141535.tif 000009
【図８】
2015141535.tif 000010
【図９】
2015141535.tif 000011
【図１０】
2015141535.tif 000012
【図１１】
2015141535.tif 000013
【図１２】
2015141535.tif 000014
【図１３】
2015141535.tif 000015
【図１４】
2015141535.tif 000016
【図１５】
2015141535.tif 000017
【図１６】
2015141535.tif 000018
【図１７】
2015141535.tif 000019
【図１８】
2015141535.tif 000020
【図１９】
2015141535.tif 000021
【図２０】
2015141535.tif 000022