(57)【要約】      （修正有）【課題】管理プロセスもメモリリークや異常終了する可能性があるが、下位プロセスの監視や指示出しを担う管理プロセスは常に稼働状態に保つ。【解決手段】管理プロセスを二重化し、実行系管理プロセスが起動後に待機系管理プロセスを起動し、処理を受け付けない状態で待機させる。実行系管理プロセスが寿命に達するまたは障害が発生したとき、実行系管理プロセスは待機系管理プロセスにデータと処理の引き継ぎを行い終了する。引き継ぎ処理により実行系管理プロセスになった待機系管理プロセスは新たな待機系管理プロセスを生成し、それを処理を受け付けない状態にして待機させる。【選択図】図１
2015146063.tif 000002
【特許請求の範囲】
【請求項１】
プロセスのメモリリークや異常終了によるサービス停止を防ぐ方法であり、
寿命を持つ（S１０１）実行系プロセスが自身の起動直後に自分と同じ待機系プロセスを、処理を受け付けない状態で起動し（S１０２）、
前記実行系プロセスが寿命に達するまたは障害を発生させた場合、前記実行系プロセス自身が終了する直前に前記待機系プロセスに処理とデータの引き継ぎを行い（S３００）、
前記引き継ぎ処理により実行系プロセスになった前記待機系プロセスが新たな待機系プロセスを、処理を受け付けない状態で起動することで（S１０２）、
プロセスのメモリリークと異常終了に対処しサービス停止を防ぐ方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プロセスのメモリリークと異常終了時の対応処理方法に係り、特に処理実行プロセスを管理する管理プロセスのメモリリークと異常終了時の対応処理方法に関する。
【背景技術】
【０００２】
メモリリークに対処する方法としては、プロセスの停止や再起動を行うのが一般的である。プロセスのメモリリークに対処するためのプロセスの停止と再起動を行う手段として、特許文献１の手法がある。この手法では、処理プロセスに処理もしくはデータに応じての増加するカウンタを持たせ、カウンタが基準値を超えたら自身を停止させることでメモリリークに対応する。また、この処理プロセスは管理プロセスによって管理され、管理プロセスからの指示により再起動をすることでもメモリリークに対処する。ここでは管理プロセスは運用者からの通知を受けたとき、または定期的に再起動の指示を処理プロセスに出す。
【０００３】
メモリリークと並んで懸念されるのがプロセスの障害発生と異常終了である。プロセスの異常終了への対策としては、プロセスの多重化が広く知られている。実行系プロセスと待機系プロセスが存在し、実行系プロセスに障害が発生すると待機系プロセスに処理が引き継がれ、システムの停止が回避される。実行系プロセスから待機系プロセスへの引き継ぎを実行するためには、やはり実行系プロセスを管理する上位プロセスが準備される。
【０００４】
特許文献２では実行系処理プロセスと待機系処理プロセス、そして実行系処理プロセスを監視する管理プロセスがあり、実行系処理プロセスの異常終了を管理プロセスが検出し、待機系処理プロセスに実行系処理プロセスを引き継ぐよう要求する。さらに管理プロセスは新たな待機系処理プロセスを起動する役割を持ち、実行系処理プロセスに対し常に待機系処理プロセスが存在するようシステムを管理する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2011-54114号公報
【特許文献２】特開平11-85556号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記２つの手法はいずれも処理プロセスのメモリリークと異常終了の対応のために処理プロセスを管理する上位プロセスとして管理プロセスが生成され、この管理プロセスからの指示によって再起動やプロセスの引き継ぎが行われる。管理プロセスは下位プロセスの監視や指示出し等の役割を担うので、管理プロセスが稼働不能な状態に陥ると下位の処理プロセスにも影響が及ぶ。そのため管理プロセスは常に稼働していることが求められ、従来技術では管理プロセスが常に稼働状態であることが前提とされている。
【０００７】
しかし実際には管理プロセス自身もメモリリークや異常終了をする可能性があり、管理プロセスに発生しうる障害に対し何も対策が取られていない状態は好ましくない。そのため管理プロセスのメモリリークと異常終了を想定した対応処理が必要である。
【課題を解決するための手段】
【０００８】
本発明の構成は、
プロセスのメモリリークや異常終了によるサービス停止を防ぐ方法であり、
寿命を持つ実行系プロセスが自身の起動直後に自分と同じ待機系プロセスを、処理を受け付けない状態で起動し、
前記実行系プロセスが寿命に達するまたは障害を発生させた場合、前記実行系プロセス自身が終了する直前に前記待機系プロセスに処理とデータの引き継ぎを行い、
前記引き継ぎ処理により実行系プロセスになった前記待機系プロセスが新たな待機系プロセスを、処理を受け付けない状態で起動することで、
プロセスのメモリリークと異常終了に対処しサービス停止を防ぐ方法である。
【発明の効果】
【０００９】
本発明によれば、管理プロセスに寿命を与え、二重化して実行系管理プロセスと待機系管理プロセスを用意することで、実行系管理プロセスが寿命に達したときに実行系管理プロセスから待機系管理プロセスに処理を引き継ぎ、管理プロセスのメモリリークを回避する。また、実行系管理プロセスの障害発生時に待機系管理プロセスへ処理を引き継ぐことで管理プロセスが常にシステムに存在する状態を作り、管理プロセス不在によるシステムの停止を防ぐ。
【００１０】
実行系管理プロセスに対し待機系管理プロセスを待機させておくことにより、管理プロセスの引き継ぎにかかる時間を最小限に抑えることができる。加えて、処理に必要なデータの引き継ぎを行うため、管理プロセスが管理する起動中の下位プロセスに与える影響が少ない。さらに待機系管理プロセスを、処理を受け付けない状態で待機させることで待機系管理プロセスのメモリー使用量を極力抑える。
【図面の簡単な説明】
【００１１】
【図１】実行系管理プロセスの処理を示す処理フローである。
【図２】プリントシステムおよびその利用者（印刷依頼者）の関係を示すユースケース図である。
【図３】印刷データ変換サービスが動作するサーバーPCのハードウエア構成図である。
【図４】サーバーPC上で動作するソフトウエアを説明するブロック図である。
【図５】印刷データ変換サービスとそれが依存するコンポーネント群を示す図である。
【図６】Service Catalogの構成を示す模式図である。
【図７】Service Inventoryの構成を示す模式図である。
【図８】実行系管理プロセスの処理の概要を示す処理フローである。
【図９】管理プロセスの引き継ぎ処理を示す処理フローである。
【図１０】待機系管理プロセスの処理を示す処理フローである。
【発明を実施するための形態】
【００１２】
本実施例では本発明を適用したサーバー上の印刷データ変換サービスについて述べる。まずは印刷データ変換サービスの構成について説明する。
【００１３】
図２は印刷データ変換サービスとその依頼者から成る構成図である。印刷データの変換を依頼する依頼者（５０）はPC（２０）、タブレットPC（３０）や携帯端末（４０）などの機器を利用し、それらの内部で動作するアプリケーションを操作して、ネットワーク（１０）上に存在する印刷データ変換サービス（２１００）に印刷データの変換を依頼する。印刷データ変換サービス（２１００）はサーバーPC（８０）上でURLを公開しているWebサービスとして動作しているプログラムである。サーバーPC（８０）上では前記URLに対して到着した依頼を印刷データ変換サービス（２１００）に転送するWebサーバー（４１００）も動作している。URLへ到着する依頼は通常多数になるため、複数のサーバーPC（８０）に処理させる構成とする。従って、複数のサーバーPC（８０）の前段にLoad Balancer（７０）を設置し各サーバーPC（８０）に転送される依頼が均一に配分されるように構成する。
【００１４】
印刷データ変換サービス（２１００）は、依頼者（５０）が指定するデータをプリンタ（６０）で印刷できる形式に変換するサービスである。依頼者（５０）が指定するデータにはドキュメント、画像ファイルなど各種のアプリケーションプログラムで作成されたフォーマットが存在する。一方、プリンタ（６０）が受け付けるデータは前述のフォーマットとは異なり、PDL( Page Description Language )で記述された印刷データや、印刷を制御するための命令とパラメータを備えたPJL( Print Job Language )で記述されたデータである。この、依頼者（５０）とプリンタ（６０）間のデータ形式の差異を埋めるのがプリンタドライバーであり、印刷データ変換サービス（２１００）はプリンタドライバーの処理をインターネット上で行うサービスである。サーバーPC（８０）上で動作している印刷データ変換サービス（２１００）は依頼者（５０）の前述した各種端末から印刷データのフォーマット変換の依頼受け、それに応じて生成した変換後のデータを直接あるいは前述した端末を経由してプリンタ（６０）に送信する。    
【００１５】
図３は印刷データ変換サービス（２１００）を実現するサーバーPC（８０）のハードウエア構成図である。印刷データ変換サービス（２１００）はOS（オペレーティングシステム）上で動作するアプリケーションプログラムであり、HDD（１００２）あるいはROM（１００３）に格納されている。CPU（１００５）がOSとアプリケーションプログラムをHDD（１００２）あるいはROM（１００３）から読み出してRAM（１００４）にロードし、実行することで様々な処理が進行する。処理結果はファイルとしてHDD（１００２）に格納され、あるいはデータとしてRAM（１００４）に記憶される。アプリケーションプログラムはコンピュータに接続されている入力装置（１００７）から使用者の入力、各種センサの読み取り値を取得する。さらに出力装置（１００６）に対して情報を出力し、処理結果を表示する。さらに、通信装置（１００８）を介してネットワークに接続された他のコンピュータや装置と通信を行う。これらのハードウエアはバス（１００１）で互いに接続されていてアプリケーションプログラムから操作できるように構成されている。
【００１６】
図４は印刷データ変換サービス（２１００）を含むソフトウエア群がサーバーPC（８０）上でどのように構成されているかを示すブロック図である。Webサーバー（４１００）は依頼者（５０）が操作したPC（２０）上のアプリケーションからHTTPプロトコルで送信されたリクエストを受け取る。Load Balancer（７０）はWebサーバー（４１００）の前段に位置し、複数のサーバーPC（８０）上で動作しているWebサーバー（４１００）に振り分ける。この振り分ける方式は種々知られているがその詳細は本発明には関係がないため説明を省略する。
【００１７】
アプリケーションサーバー（４２００）は要求の送付先として指定されたURLを解析し、関連つけられている印刷データ変換サービス（２１００）を決定するソフトウエアである。本実施例では複数種あるサービスの一つが印刷データ変換サービス（２１００）であることを想定している。
【００１８】
印刷データ変換サービス（２１００）は単一のプロセスではなく、複数プロセスが共同して動作することでサービスを提供する。Locator（２５００）とLogger（２６００）は印刷データ変換サービス（２１００）とは独立して存在する管理プロセスである。アプリケーションサーバー（４２００）は複数の要求を並列実行させるために、印刷データ変換サービス（２１００）を複数起動し、各々に要求を振り分ける。この場合でも、Locator（２５００）とLogger（２６００）はそれぞれ一個のプロセスとして存在している。Logger（２６００）は本発明には関係がないため以降説明を省略する。
【００１９】
（印刷データ変換サービス）
図５は印刷データ変換サービス（２１００）の動作に関連するソフトウエアコンポーネント群の関連を説明する図である。印刷データ変換サービス（２１００）は先に説明したように複数のプロセスの共同体として動作している。その構成要素はPrint Service Gateway（２１１０）、Proxy（２２００）、Filter Host（２４００）と各種Filter群（２４１０，２４１１）となっている。Filterは多数存在し、その組み合わせは固定化されていない。
【００２０】
（Print Service Gateway）
印刷データ変換サービス（２１００）に対するサービス依頼を受け付けるのはプロセスとして存在するPrint Service Gateway（２１１０）であり、その起動はアプリケーションサーバー（４２００）が行う。Print Service Gateway（２１１０）はProxy（２２００）をロードし、そのProxy（２２００）が後述するJob Controller（２３００）に受け付けた変換処理の実行を依頼し、変換処理の結果を受領する。
【００２１】
（Locator）
印刷データ変換サービス（２１００）を構成するコンポーネント群が利用するLocator（２５００）は特別な役割を担っている管理プロセスである。Locator（２５００）はアプリケーションサーバー（４２００）が起動した時点で既に起動している特殊なプロセスである。Locator（２５００）の起動の方法はサーバーPC（８０）上で動作しているオペレーティングシステム（OS）によって種々の方法が存在する。例えば、Windows（登録商標）であれば”Windows Service”というシステム起動時に自動的に起動される特殊なプロセスとして実装することが可能であり、Linux （登録商標）やUnix（登録商標）ではデーモンプロセスとして動作させることが可能である。
【００２２】
Locator（２５００）はコンポーネントの生成の責務を担っている。さらに他のコンポーネントからの求めに応じて別のコンポーネントのアクセスポイントを返すという機能を提供する。アクセスポイントとはTCP/IPのリスンポートを指す。あるコンポーネントは別のコンポーネントが公開しているアクセスポイントを取得し、そのアクセスポイントにアクセスすることでそのコンポーネントが提供する機能を利用する。あるコンポーネントが他のコンポーネントのアクセスポイントをLocator（２５００）に対して問い合わせる動作を “クエリー”と呼ぶ。クエリーの詳細は後述する。
【００２３】
（Job Controller）
Proxy（２２００）を介してデータ変換のジョブ実行を依頼されたJob Controller（２３００）はジョブおよび、ジョブに含まれている印刷データを解析して変換に必要なFilterを選定し、これらFilterをロードしているFilter Host（２４００）を取得する。Filterの組み合わせとその変換順番は固定的な知識としてJob Controller（２３００）に実装されている。
【００２４】
Job Controller（２３００）は自身と各Filter（２４１０，２４１１）、そしてProxy（２２００）との間にPipeline（３０００）と呼ばれるデータ転送チャネルを作成する。図５のようにPipeline（３０００）を作成することで、Proxy（２２００）から印刷データが複数のコンポーネントを還流し、最後に変換が終了した形で再びProxy（２２００）に戻ってくる。
【００２５】
（Filter、Filter Host）
Filterはデータ変換処理のみを実装したライブラリーモジュールの形式で用意されている。Filter Host（２４００）はプロセスとして存在し、実行時に指定されたFilterをロードする。Filter Host（２４００）はControl Bus（３１００）への接続とメッセージ送受信、Job Controller（２３００）との通信などの処理を担当する。
【００２６】
ここで、印刷データ変換サービス（２１００）を構成しているコンポーネント群が他のコンポーネントをクエリーする意義と手順を説明する。
【００２７】
（クエリーの意義）
コンポーネントが提供しているサービスはネットワークからアクセスできるエンドポイントとして他のコンポーネントに公開される。具体的にはTCP/IPのアドレスとポート番号の組が公開される。コンポーネントは他のコンポーネントの提供するサービスI/Fを取得して利用する。複数種類のコンポーネントがプロセスとして複数存在し、かつ同一コンポーネントも同一PC上に複数存在する。従って、各コンポーネントが公開するサービスI/Fのポート番号は固定にすることができないため、動的に生成せざるを得なくなる。動的に生成されたエンドポイントは何らかの管理機構が無くては他から参照することはできない。この管理を担当するのはLocator（２５００）である。さらに、コンポーネントが他のコンポーネントの動的に生成されたエンドポイントを取得する手段が必要である。この手段がクエリーである。クエリーに回答するのはLocator（２５００）の役割である。
【００２８】
（コンポーネントの生成）
Locator（２５００）は図６に示すService Catalog（５００１）を保持している。Service Catalog（５００１）はサーバーPC（８０）上にインストールされているコンポーネントのリストで構成されている。コンポーネントごとに名前、バージョン、実行ファイルパス、起動時のコンフィギュレーションファイルパス、コンポーネントの寿命、起動モードが格納されている。
【００２９】
Locator（２５００）は自身の起動後、Service Catalog（５００１）を参照し、起動モードがホットスタンバイに指定されているコンポーネントを起動する。起動モードにはそのほかにオンデマンド（on-demand）が定義されている。オンデマンドの起動モードを持つコンポーネントは、そのコンポーネントを指定したクエリーがなされて初めて起動される。
【００３０】
コンポーネントは起動が完了し、他のコンポーネントへのサービスの提供の準備ができると、Control Bus（３１００）に自身のAdvertise Messageを作成してLocator（２５００）宛てに送信する。Advertise Messageにはコンポーネントの名前、ID、バージョン、サービスI/FのURL、ポート番号、寿命が記載されている。このメッセージの受信によってLocator（２５００）はコンポーネントの起動を確認し、かつサービスI/Fを取得することができる。Locator（２５００）はコンポーネントからのAdvertise Messageを受信すると、管理テーブルであるService Inventory（５００２）にメッセージの送信元であるコンポーネントのエントリーを作成し、そこにメッセージの内容を転記して登録を行う。
【００３１】
（コンポーネントの管理）
Locator（２５００）は各コンポーネントからメッセージを受け取るたびにService Inventory（５００２）の該当するエントリーの情報を更新し、コンポーネントを管理する。図７はService Inventory（５００２）の内容を模式的に表した図である。「生存時間」欄にはコンポーネントが作成されてからの時間（秒数）が、「状態」欄にはコンポーネントの現在の状態を示す値が記録される。これらは各コンポーネントから送信されるメッセージとその内容によって更新される。「最終連絡時刻」欄にはLocator（２５００）がコンポーネントから最後に受け取ったメッセージの受け取り時刻が記録される。
【００３２】
寿命に達したコンポーネントはLocator（２５００）宛てにGoodbye Messageを送信する。Locator（２５００）はGoodbye Messageを受信すると、対象コンポーネントのエントリーをService Inventory（５００２）から削除する。
【００３３】
コンポーネントが他のコンポーネントを利用するときはLocator（２５００）を経由する必要がある。例えばコンポーネントAがコンポーネントBを利用しようとするとき、まずコンポーネントAはLocator（２５００）に対してクエリーする。この時点でコンポーネントBがまだ生成されていない場合、Locator（２５００）はコンポーネントBを新たに生成する。Service Inventory（５００２）に記録されたコンポーネントBの「状態」がビジー状態でなければ、Locator（２５００）はコンポーネントBインスタンスを選定し、コンポーネントAのクエリーに対してレスポンスメッセージを返却する。レスポンスメッセージにはコンポーネントBの名前、バージョン、サービスI/Fを示すURLとポート番号が格納されている。コンポーネントAはレスポンスメッセージを受け取るとコンポーネントBのサービスI/Fを利用することができる。
【００３４】
以上が印刷データ変換サービスの構成に関する説明である。
【００３５】
続いて、本発明の特徴となるLocator（２５００）について説明する。
【００３６】
Locator（２５００）は二重化されており、ひとつは実行系プロセスとして、もうひとつは待機系プロセスとして存在する。以降、それぞれを実行系Locator（２５１０）と待機系Locator（２５２０）と呼ぶ。各Locator（２５１０、２５２０）には起動時間または処理に応じた寿命が設定されており、実行系Locator（２５１０）は寿命に達するまで後述するコンポーネントの生成や管理等の処理を行う。実行系Locator（２５１０）は寿命に達する、または障害が発生すると、待機系Locator（２５２０）にプロセスを引き継ぐ処理を実行する。
【００３７】
（待機系Locatorの生成）
図１は実行系Locator（２５１０）の処理（S１００）のフローを表す。実行系Locator（２５１０）は起動直後に自身の寿命を設定する（S１０１）。実行系Locator（２５１０）の寿命のカウントは、起動されてからの時間と処理したジョブの数に依存する。寿命設定後、実行系Locator（２５１０）は自分自身と同じプログラムを起動し（S１０２）、これを待機系Locator（２５２０）とする。待機系Locator（２５２０）は他のコンポーネントとは異なり、起動後にAdvertise Messageを実行系Locator（２５１０）に送信しない。Advertise Messageを送信しないことにより、待機系Locator（２５２０）は他のコンポーネントからのクエリーを受け付けない状態を保つ。これにより、待機系Locator（２５２０）が待機中に使用するメモリーを最小限に抑えることができる。実行系Locator（２５１０）は待機系Locator（２５２０）の生成を終えると処理のイベントループに入る（S２００）。
【００３８】
（Locatorの引き継ぎ）
図８は実行系Locator（２５１０）のイベントループ（S２００）を表す。実行系Locator（２５１０）は寿命に達した場合（S２０２）と、自身に障害が発生した場合（S２０１）に処理を待機系Locator（２５２０）に引き継ぎ（S３００）、プロセスを終了する。プロセスの引き継ぎ（S３００）は実行系Locator（２５１０）自身が実行する処理であり、前記寿命到達（S２０２）と障害発生（S２０１）のいずれの場合も引き継ぎ処理（S３００）を行う同じプログラムが呼び出され実行される。
【００３９】
実行系Locator（２５１０）は定期的に自身の寿命を確認し、寿命に達したとき（S２０２）にプロセスの引き継ぎ（S３００）を実行する。寿命に達した際、実行系Locator（２５１０）がメッセージの受け渡し等の処理中であれば、その処理が終了した後で引き継ぎ（S３００）を行う。実行系Locator（２５１０）に障害が発生した場合（S２０１）は、実行系Locator（２５１０）を終了させる前に引き継ぎ処理（S３００）が実行される。障害発生時のプロセス引き継ぎ処理の実行方法として、プロセスの障害発生時に動作するハンドラに、自身のプロセス引き継ぎ処理を呼び出すよう実行系Locator（２５１０）が予め依頼しておく方法がある。Locator（２５００）の引き継ぎ処理（S３００）を実行するのは実行系Locator（２５１０）であり、上記障害発生時に動作するハンドラは実行系Locator（２５１０）に指定されたプログラムを実行するための合図を出す役割のみを担う。
【００４０】
図９と図１０はそれぞれ、実行系Locator（２５１０）から待機系Locator（２５２０）への引き継ぎ処理（S３００）と、待機系Locator（２５２０）の処理（S４００）のフローを示す。引き継ぎ処理（S３００）ではまず、実行系Locator（２５１０）が保持する情報が格納されたパスが待機系Locator（２５２０）に渡される（S３０１、S４０２）。実行系Locator（２５１０）が保持する情報には前述したService Catalog（５００１）とService Inventory（５００２）がある。実行系Locator（２５１０）はService Catalog（５００１）とService Inventory（５００２）のパスが記入されたWakeup Messageを待機系Locator（２５２０）に送信する。
【００４１】
待機系Locator（２５２０）はWakeup Massageを受信するまでは他のメッセージを受け取っても処理をせず、Wakeup Messageを受け取るまで待機する（S４０１）。実行系Locator（２５１０）が保持する情報を待機系Locator（２５２０）が受け取ることにより、印刷データ変換サービス（２１００）は実行中の変換処理を中断することなく、起動中のコンポーネントをそのまま利用して処理を続けることが可能となる。続いて、実行系Locator（２５１０）が持つTokenが、待機系Locator（２５２０）に渡される（S３０２、S４０３）。このTokenは実行系Locator（２５１０）の複数同時起動を阻止するもので、これを持つLocatorは印刷データ変換サービス（２１００）の実行系Locator（２５１０）として起動する権限が与えられる。実行系Locator（２５１０）はTokenを待機系Locator（２５２０）に渡すと自身のプロセスを終了する。S４０３でTokenを受け取った待機系Locator（２５２０）は新たな実行系Locatorとして、実行系Locatorの寿命が設定され（S１０１）、自身の後を継ぐ待機系Locatorを作成する（S１０２）。
【符号の説明】
【００４２】
2100・・・印刷データ変換サービス
2510・・・実行系Locator
2520・・・待機系Locator
5001・・・Service Catalog
5002・・・Service Inventory
【図１】
2015146063.tif 000003
【図２】
2015146063.tif 000004
【図３】
2015146063.tif 000005
【図４】
2015146063.tif 000006
【図５】
2015146063.tif 000007
【図６】
2015146063.tif 000008
【図７】
2015146063.tif 000009
【図８】
2015146063.tif 000010
【図９】
2015146063.tif 000011
【図１０】
2015146063.tif 000012