JP2016042338A - 情報処理システム、情報処理装置、情報処理装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】ジョブの並列処理において、単一外部プロセスで障害が発生した場合であっても、単一外部プロセスの障害によって停止・失敗する処理の数を最小限に抑えることができる情報処理システムを提供する。【解決手段】この情報処理システムは、単一プロセスを共有して複数のジョブの並列処理を行う情報処理システムであって、単一プロセスにおいてジョブを処理中に発生した異常を検出する検出手段と、検出手段により異常が検出された場合に単一のプロセスに依頼された新たなジョブを待機させる待機手段と、単一プロセスを再起動させる起動手段と、単一プロセスの再起動後に異常の発生時に処理中であったジョブを単一プロセスに再処理させる処理手段とを備える。【選択図】 図１１

Description

本発明は、情報処理システム、情報処理装置、情報処理装置の制御方法、及びプログラムに関し、特に、複数のジョブが単一のプロセスを共有し並列処理を行う情報処理システムにおける、単一プロセスの管理と情報処理システムの障害復旧方法に関する。

計算機上のマルチプロセスで動作する情報処理システムにおいて、生成された複数のプロセスがシステム内の単一のプロセスを共有して使用することがある。プロセスには、ＯＳ（オペレーティングシステム）上に同じプロセスを複数生成して動作することが可能なものと、同じプロセスをＯＳ上にひとつしか生成できないものが存在する。また、後者には、生成された単一プロセスで単一のジョブしか受け付けないものと、単一プロセスで複数のジョブを受けられ、それらを並列に処理できるもの（以降、「並列処理可能な単一プロセス」という）がある。

並列処理可能な単一プロセスを複数プロセスで共有するとき、通常、並列処理されるジョブは、互いに影響を及ぼすことはない。そのため、ジョブの依頼主となるプロセスは、他プロセスを意識することなく単一プロセスにジョブを依頼し、単一プロセスは依頼されたジョブを待機させることなく処理することができる。

なお、並列処理されるジョブが互いに影響を及ぼさないのは、単一プロセスでの処理が正常に行われている場合に限られる。従って、並列処理可能な単一プロセスで障害が発生すると、単一プロセスで処理中のすべての処理が続行不能となり処理に失敗する。さらに、単一プロセスが復旧するまでの間に単一プロセスに新たに依頼される処理も受け付けられることなく失敗する。

失敗を防ぐために、例えば、排他制御が挙げられる。例えば、特許文献１では、複数のノードから成る計算機システムにおいて、各ノードに共有プロセスが他ノードに占有されているか否かを判断する手段を設ける方法が開示されている。共有プロセスが他ノードに占有されている場合、各ノードは、他ノードから共有プロセスの開放が通知されるまでは自身からのジョブを待機させることで排他処理を行う。また、各ノードは、共有プロセスを占有中の他ノードに障害が発生したとき、他ノードによる共有プロセスの占有を解き、共有プロセスをジョブの受け付けが可能な状態にリカバリする手段を有する。

特開平１１−２０３２５４号公報

しかしながら、排他制御を行うと一度にひとつのジョブしか処理できないため、ジョブ数が多い場合や各ジョブの処理時間が長い場合に、処理効率が著しく低下する。そのため、処理効率を重視するシステムでは複数ジョブを並列処理することが多い。

複数ジョブを並列処理するシステムでは、仕様変更のできない単一プロセス（以下、「単一外部プロセス」という）を複数プロセスで共有している。単一外部プロセスは、処理の途中経過を他のプロセスに通知しないため、単一外部プロセスを使用する他のプロセスは、単一外部プロセスにジョブを依頼した時刻からの経過時間を元に単一外部プロセスの処理状態を判断する。単一外部プロセスに依頼されるジョブは、制限時間を有し、制限時間内に処理が終了せずタイムアウトした場合は、単一外部プロセスが異常状態にある、つまり障害が発生したと判断される。そのため、単一外部プロセスにおいて実際に障害が発生した時刻とシステムが障害を認識する時刻には差が生じる。言い換えると、システム上では、単一外部プロセスの障害にすぐに気づくことができない。単一外部プロセスを使用したい他プロセスは、単一外部プロセスで障害が発生していても、システムが障害を認識するまでは、単一外部プロセスにジョブを依頼する。そのため、他プロセスのジョブもすべて処理に失敗してしまう。

本発明は、上記の問題に鑑みて、ジョブの並列処理において、単一外部プロセスで障害が発生した場合であっても、単一外部プロセスの障害によって停止・失敗する処理の数を最小限に抑えることができる情報処理システムを提供することを目的とする。

上記課題を解決するために、本発明の情報処理システムは、複数のジョブが単一プロセスを共有して並列処理を行う情報処理システムであって、前記単一プロセスにおいてジョブを処理中に発生した異常を検出する検出手段と、前記検出手段により前記異常が検出された場合に前記単一のプロセスに依頼された新たなジョブを待機させる待機手段と、前記単一プロセスを再起動させる起動手段と、前記単一プロセスの再起動後に前記異常の発生時に処理中であったジョブを前記単一プロセスに再処理させる処理手段とを備えることを特徴とする。

本発明によれば、単一外部プロセスで障害が発生した場合であっても、障害に巻き込まれて失敗したジョブに対し、単一外部プロセスでの処理をリトライするチャンスを与えながら、単一外部プロセスを正常状態に復旧させることができる。また、復旧処理中に単一外部プロセスに依頼されるジョブを待機させ、新たに障害に巻き込まれるジョブがないようにすることで、単一外部プロセスの障害によって停止・失敗する処理の数を最小限に抑えることができる。

プリントシステム全体の構成を示す図である。 サーバーＰＣのハードウエア構成を示すブロック図である。 サーバーＰＣ上で動作するソフトウエア構成を示すブロック図である。 印刷データ変換サービスの構成するコンポーネント群を示す図である。 単一外部プロセスに５つのジョブの依頼が届く場合の構成を示す図である。 管理プロセスのイベントループを示すフローチャートである。 管理プロセスの処理を示すフローチャートである。 単一外部プロセスを使用するときの正常時のシーケンス図である。 単一外部プロセスでリトライをするときのシーケンス図である。 単一外部プロセスの使用を待機する場合のシーケンス図である。 単一外部プロセスの異常時における処理を示すフローチャートである。 第２実施形態で対応する、単一外部プロセスの課題を示す図である。 各ジョブのリトライのタイミングを示す図である。 ジョブを特定するときの処理を示すフローチャートである。 Ｆｉｌｔｅｒプロセスの処理を示すフローチャートである。 障害の復旧を開始するときの処理を示すフローチャートである。 ジョブを探すときの処理の一部を示すフローチャートである。 ジョブを特定した後の処理を示すフローチャートである。

以下、本発明を実施するための形態について図面などを参照して説明する。

まず、図１は、本実施形態に係るプリントシステム全体の構成を示す図である。プリントシステム（情報処理システム）は、依頼者５０と、依頼者５０の各種端末２０、３０および４０と、プリンタ６０と、Ｌｏａｄ Ｂａｌａｎｃｅｒ７０と、サーバーＰＣ８０を含む。本実施形態では、各種端末２０、３０および４０は、それぞれ、ＰＣ２０、タブレットＰＣ３０や携帯端末４０であるが、これに限定することなく、他の情報処理装置（端末）であってもよい。プリンタ６０は、印刷処理装置であり、印刷機能のみを備えるプリンタであってよく、印刷機能、スキャン機能、複写機能等を備えるマルチファンクションプリンタ（ＭＦＰ）であってもよい。なお、サーバーＰＣ８０は、複数台あってよく、それぞれがＬｏａｄ Ｂａｌａｎｃｅｒ７０と接続されている。

依頼者５０が印刷を行う際、依頼者５０が指定するデータは、ネットワーク１０を介してサーバーＰＣ８０にてプリンタ６０で印刷できる形式に変換され。サーバーＰＣ８０は、依頼者５０の各種端末２０〜４０から印刷データのフォーマット変換の依頼受けると、それに応じて生成した変換後のデータを直接あるいは依頼者５０の端末を経由してプリンタ６０に送信する。そして、プリンタ６０にて、印刷が行われる。具体的には、印刷データの変換を依頼する依頼者５０は、ＰＣ２０などの機器を利用し、それら内部で動作するアプリケーションからネットワーク１０上に存在する後述する印刷データ変換サービス２１００に印刷データの変換を依頼する。印刷データ変換サービス２１００は、サーバーＰＣ８０上の後述するＷｅｂサービスとして動作しているプログラムである。サーバーＰＣ８０上では、依頼者５０からの変換依頼を印刷データ変換サービス２１００に転送するＷｅｂサーバー４１００（図３に示す）も動作している。印刷データ変換サービス２１００は、複数のサーバーＰＣ８０上で動作する。ネットワーク１０とサーバーＰＣ８０との間に設置されたＬｏａｄ Ｂａｌａｎｃｅｒ７０は、各サーバーＰＣ８０に依頼者５０からの依頼を均一に配分し転送する。

次に、図２は、印刷データ変換サービス２１００を実現するサーバーＰＣ８０のハードウエア構成図である。印刷データ変換サービス２１００は、オペレーティングシステム（ＯＳ）上で動作するアプリケーションプログラムであり、ハードディスク（ＨＤＤ）１００２またはＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１００３に格納されている。ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１００５は、ＯＳとアプリケーションプログラムをＨＤＤ１００２またはＲＯＭ１００３から読み出してＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１００４にロードし実行する。処理結果は、ファイルとしてＨＤＤ１００２に格納、またはデータとしてＲＡＭ１００４に記憶される。アプリケーションプログラムは、サーバーＰＣ８０に接続されている入力装置１００７から依頼者５０等のユーザの入力、各種センサの読み取り値を取得する。出力装置１００６に対しては、情報を出力し、処理結果を表示する。さらに、通信装置１００８を介してネットワークに接続された他のコンピュータや装置と通信を行う。これらのハードウエアは、バス１００１で互いに接続されていてアプリケーションプログラムから操作できるように構成されている。

図３は、サーバーＰＣ８０上の印刷データ変換サービス２１００を含むソフトウエア群の構成図である。Ｗｅｂサーバー４１００は、依頼者５０が操作したＰＣ２０（または、タブレットＰＣ３０や携帯端末４０）上のアプリケーションからＨＴＴＰプロトコルで送信されたリクエストを受け取る。Ｌｏａｄ Ｂａｌａｎｃｅｒ７０は、Ｗｅｂサーバー４１００の前段に位置し、複数のサーバーＰＣ８０上で動作しているＷｅｂサーバー４１００に振り分ける。この振り分ける方式は種々知られている従来の方式を適用してよく、その詳細の説明は、省略する。Ｌｏｃａｔｏｒ２５００は、印刷データ変換サービス２１００とは独立して存在する管理プロセスである。アプリケーションサーバー４２００は、要求の送付先に関連つけられている印刷データ変換サービス２１００を決定するソフトウエアである。そして、複数の要求を並列実行させるために、印刷データ変換サービス２１００を複数起動し、各々に要求を振り分ける。この場合でも、Ｌｏｃａｔｏｒ２５００は、１個のプロセスとして存在している。

図４は、印刷データ変換サービス２１００の構成を示す。印刷データ変換サービス２１００は、複数プロセスが共同して動作することでサービスを提供する。印刷データ変換サービス２１００は複数のプロセスの共同体として動作する。構成要素は、Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ２１１０、Ｐｒｏｘｙ２２００、Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００、Ｌｏｃａｔｏｒ２５００、Ａｃｔｉｖａｔｏｒ２５５０、Ｆｉｌｔｅｒ Ｈｏｓｔ２４００と各種Ｆｉｌｔｅｒ群となっている。これらは同一のＣｏｎｔｒｏｌ Ｂｕｓ５００２でつながっている。印刷データ変換サービス２１００は、同一のＣｏｎｔｒｏｌ Ｂｕｓ５００２上に複数起動され、複数の要求を並列実行する。

印刷データ変換サービス２１００では、まず、Ｐｒｏｘｙ２２００は、データ変換の依頼を受け取り、Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００に変換処理の実行を依頼する。Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００は、変換処理内容に合わせてＦｉｌｔｅｒ群を用意し、Ｐｒｏｘｙ２２００、Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００、Ｆｉｌｔｅｒ Ｈｏｓｔ２４００をＰｉｐｅｌｉｎｅ３０００と呼ばれるデータ転送チャネルで繋ぐ。そして、Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００は、用意されたＦｉｌｔｅｒ群に変換処理を依頼する。Ｆｉｌｔｅｒ群の中には、Ｅｘｔｅｒｎａｌ Ｐｒｏｃｅｓｓ２７００ (以降、「単一外部プロセス」という)を用いて変換処理を行うＦｉｌｔｅｒもある。Ｆｉｌｔｅｒで変換された結果は、Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００を経由し、Ｐｒｏｘｙ２２００へと渡される。ここで、本実施形態の主要コンポーネントの役割を説明する。

（単一外部プロセス）
単一外部プロセス２７００は、ＯＳ上で１つしか生成できないプロセスであり、複数のジョブを並列に処理することが可能なプロセスである。印刷データ変換サービス２１００では、複数のＦｉｌｔｅｒが単一外部プロセス２７００を共有し、それぞれのジョブを排他制御せずに単一外部プロセス２７００に依頼している。

（Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ）
印刷データ変換サービス２１００に対するサービス依頼を受け付けるのは、プロセスとして存在するＰｒｉｎｔ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ２１１０であり、アプリケーションサーバー４２００が起動する。Ｐｒｉｎｔ Ｓｅｒｖｉｃｅ Ｇａｔｅｗａｙ２１１０は、Ｐｒｏｘｙ２２００をロードし、そのＰｒｏｘｙ２２００がＪｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００に受け付けた変換処理の実行を依頼し、変換処理の結果を受領する。

（Ｌｏｃａｔｏｒ）
Ｌｏｃａｔｏｒ２５００は、印刷データ変換サービス２１００を構成するコンポーネント群を管理するプロセスである。Ｌｏｃａｔｏｒ２５００は、他のコンポーネントからの求めに応じて別のコンポーネントのアクセスポイントを返すという機能を有する。ここで、アクセスポイントとは、ＴＣＰ／ＩＰのリスンポートを指す。あるコンポーネントは、別のコンポーネントのアクセスポイントにアクセスすることで該コンポーネントが提供する機能を利用する。また、あるコンポーネントが他のコンポーネントのアクセスポイントをＬｏｃａｔｏｒ２５００に問い合わせる動作を「クエリー」と呼ぶ。Ｌｏｃａｔｏｒ２５００は、あるコンポーネントからまだ生成されていない他のコンポーネントのアクセスポイントをクエリーされると、後述するＡｃｔｉｖａｔｏｒ２５５０にコンポーネントの生成を依頼する。

Ｌｏｃａｔｏｒ２５００は、Ａｃｔｉｖａｔｏｒ２５５０が生成したコンポーネントの情報を保持し管理する。単一外部プロセス２７００を管理するのもＬｏｃａｔｏｒ２５００の役割である。Ｌｏｃａｔｏｒ２５００は、単一外部プロセス２７００の状態を管理するための管理シートを有する。なお、管理シートを以降、ＥＰ Ｓｈｅｅｔと呼ぶ。ＥＰ Ｓｈｅｅｔは、単一外部プロセス２７００ごとに存在し、Ｌｏｃａｔｏｒ２５００は、システムで使用される単一外部プロセス２７００の数だけＥＰ Ｓｈｅｅｔを有する。ＥＰ Ｓｈｅｅｔには、単一外部プロセス２７００のＩＤ、名前、ステータス、単一外部プロセス２７００を使用中のＦｉｌｔｅｒのリスト（使用中リスト）が登録されている。また、単一外部プロセス２７００へのジョブ依頼を待機しているＦｉｌｔｅｒのリスト(待機中リスト)も登録されている。単一外部プロセス２７００のステータスは、「不在」、「処理可能」、「異常」の３種類で管理される。Ｌｏｃａｔｏｒ２５００は、必要に応じてＥＰ Ｓｈｅｅｔの内容を更新し、その内容によって処理を変更する。詳しい処理については後述する。

また、Ｌｏｃａｔｏｒ２５００は、アプリケーションサーバー４２００が起動した時点で既に起動しているプロセスである。Ｌｏｃａｔｏｒ２５００の起動の方法は、サーバーＰＣ８０上で動作しているオペレーティングシステム（ＯＳ）によって種々の方法が存在する。例えば、Ｗｉｎｄｏｗｓ（登録商標）であれば「Ｗｉｎｄｏｗｓ（登録商標） Ｓｅｒｖｉｃｅ」というシステム起動時に自動的に起動される特殊なプロセスとして実装することが可能である。また、Ｌｉｎｕｘ（登録商標）やＵｎｉｘ（登録商標）ではデーモンプロセスとして動作させることが可能である。さらに、Ｌｏｃａｔｏｒ２５００は、他のコンポーネントからの求めに応じて別のコンポーネントのアクセスポイントを返すという機能を提供する。

（Ａｃｔｉｖａｔｏｒ）
Ａｃｔｉｖａｔｏｒ２５５０は、コンポーネントの生成の責務を担う。また、Ａｃｔｉｖａｔｏｒ２５５０は、生成したコンポーネントのプロセスＩＤを管理し、コンポーネントの削除も行う。コンポーネントには、自ら自分の寿命を管理するものとしないものがあり、Ａｃｔｉｖａｔｏｒ２５５０は、自分で寿命の管理をしないコンポーネントの寿命管理を担う。起動してからある一定時間が経過し、かつ待機中であるコンポーネントがあれば、Ａｃｔｉｖａｔｏｒ２５５０は、それを終了させる。また、Ａｃｔｉｖａｔｏｒ２５５０は、Ｌｏｃａｔｏｒ２５００からコンポーネントの生成または削除の依頼を受けると、対象となるコンポーネントを生成または削除し、処理が完了するとＬｏｃａｔｏｒ２５００に通知する。

（Ｆｉｌｔｅｒ、Ｆｉｌｔｅｒ Ｈｏｓｔ）
Ｆｉｌｔｅｒは、データ変換処理のみを実装したライブラリーモジュールの形式で用意する。Ｆｉｌｔｅｒ Ｈｏｓｔ２４００は、プロセスとして存在し、実行時に指定されたＦｉｌｔｅｒをロードする。Ｆｉｌｔｅｒ Ｈｏｓｔ２４００は、Ｃｏｎｔｒｏｌ Ｂｕｓ５００２への接続とメッセージ送受信、Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００との通信などの処理を担当する。以後、ＦｉｌｔｅｒとＦｉｌｔｅｒ Ｈｏｓｔ２４００をひとつのコンポーネントとしてまとめてＦｉｌｔｅｒと呼ぶ。

Ｆｉｌｔｅｒは、Ｆｉｌｔｅｒからさらに別のプロセスにジョブを依頼することで変換処理を実現している。Ｆｉｌｔｅｒによって使用されるプロセスの中には、単一外部プロセス２７００が存在する。例えば、図４において、単一外部プロセス２７００が３つのＦｉｌｔｅｒ２４０１、２４０２および２４０３に共有されている場合を示す。以上が主要コンポーネントについての説明である。ここから、システムの詳細について説明する。

（リトライ）
単一外部プロセス２７００に依頼したジョブが処理に失敗した場合、再度同じジョブを単一外部プロセス２７００に依頼し、処理をやり直すことをリトライ（再処理）と呼ぶ。複数のジョブが並列処理されている単一外部プロセス２７００において、ある１つのジョブによって異常状態が発生すると、処理中のジョブがすべて失敗してしまう。そこで、異常に巻き込まれて失敗したジョブにリトライする権利を与え、単一外部プロセス２７００が復旧した後にジョブのやり直しを行う。リトライをすることで、単一外部プロセス２７００の異常を引き起こしたジョブ以外のジョブが処理に失敗する事態を回避することができる。

（Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ）
Ｐｒｏｘｙ２２００を介してデータ変換ジョブを依頼されたＪｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００は、ジョブを解析して変換に必要なＦｉｌｔｅｒを選定し、これらＦｉｌｔｅｒをロードしているＦｉｌｔｅｒ Ｈｏｓｔ２４００を取得する。Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００は、自身と各Ｆｉｌｔｅｒ、そしてＰｒｏｘｙ２２００との間にＰｉｐｅｌｉｎｅ３０００と呼ばれるデータ転送チャネルを作成する。図２のようにＰｉｐｅｌｉｎｅ３０００を作成することで、Ｐｒｏｘｙ２２００から印刷データが複数のコンポーネントを還流し、最後に変換が終了した形で再びＰｒｏｘｙ２２００に戻る。

（ジョブ）
ジョブは、概念的には変換されるべき対象データと変換処理用の設定値などをまとまりのある形式に束ねたデータ構造から構成される。ジョブには、識別できるようにユニークな識別情報が与えられる（ジョブＩＤ）。生成されたジョブは、ファイルとして記憶装置に格納される。また、記憶装置から取り出す際にはジョブＩＤを指定してそのファイルを取得して内容を参照することが可能である。また、ジョブを破棄する行為は、ファイルの削除として実現される。ジョブは、この印刷データの内容を直接ファイル内に含むか、あるいはファイル化した印刷データのファイルパスなどの参照情報を含む。

（第１実施形態）
本実施形態では、単一外部プロセス２７００で障害が発生した場合、単一外部プロセス２７００で処理中であるジョブのうち、最も古いジョブが単一外部プロセス２７００の障害の原因だとして障害復旧を行う。これは、各ジョブが短時間で処理され、単一外部プロセス２７００で複数のジョブが同時に処理される確率が低い場合に有効である。また、単一外部プロセス２７００での実際の処理時間に対し、タイムアウトまでの時間が比較的長い場合に対しても効果的である。

図５は、単一外部プロセス２７００に５つのＦｉｌｔｅｒ７２１０〜７２５０からジョブの依頼が届く場合の概略図である。単一外部プロセス２７００とＦｉｌｔｅｒ群は、管理プロセスによって管理されている。本実施形態では、Ｆｉｌｔｅｒ１ ７２１０からのジョブ（Ｊｏｂ１）を単一外部プロセス２７００で処理している際に、単一外部プロセス２７００で異常が発生したとする。単一外部プロセス２７００に依頼されるジョブは、制限時間を有し、制限時間内に処理が終了せずにタイムアウトした場合、単一外部プロセス２７００が異常状態にあると判定する。図５では、実線の矢印がジョブの進行度合いを示し、その矢印の下の灰色の線がジョブの制限時間を示す。本実施形態では、Ｊｏｂ１の処理中に異常が発生してから、Ｊｏｂ１がタイムアウトするまでの間にＦｉｌｔｅｒ２ ７２２０、Ｆｉｌｔｅｒ３ ７２３０、Ｆｉｌｔｅｒ４ ７２４０からそれぞれＪｏｂ２、Ｊｏｂ３、Ｊｏｂ４が依頼されたとする。さらに、Ｊｏｂ１がタイムアウトした直後にＦｉｌｔｅｒ５ ７２５０がＪｏｂ５を単一外部プロセス２７００に依頼しようとしているとする。

このとき、単一外部プロセス２７００で処理中のジョブのうち、最も古いジョブが異常の原因だと管理プロセスは判定する。そこで、管理プロセスは、Ｊｏｂ１以外のジョブが異常状態に巻き込まれて失敗するのを防ぐための処理を行う。まず、Ｊｏｂ５は、単一外部プロセス２７００が異常状態であると判定された後の依頼なので、管理プロセスは、単一外部プロセス２７００を正常状態に復旧させるまでＪｏｂ５を待機させる。ジョブを待機させるとは、単一外部プロセス２７００へのジョブの依頼を、許可を出すまで実行させないということである。Ｊｏｂ２、Ｊｏｂ３、Ｊｏｂ４は、単一外部プロセス２７００に既に依頼されているジョブである。しかし、これらは、単一外部プロセス２７００が異常状態であるため、処理が進行せず失敗する。そこで、管理プロセスは、これら３つのジョブに対し、単一外部プロセス２７００が正常状態に復旧した後、ジョブを単一外部プロセス２７００に依頼しなおすよう指示をする。このように、ジョブをやり直し、または待機させることで単一外部プロセス２７００における障害に巻き込まれて失敗するジョブを最小限に抑える。

（単一外部プロセスのステータスによる動作の変化）
図６は、単一外部プロセス２７００に関するＬｏｃａｔｏｒ２５００のイベントループ処理を示す。まず、Ｌｏｃａｔｏｒ２５００は、Ｆｉｌｔｅｒから、クエリーを受け取ったか否かを判定する（ステップＳ００１）。クエリーを受け取った場合（Ｙｅｓ）、ステップＳ１００に進み、ジョブ受信時の処理を行い（ステップＳ１００）、ステップＳ００１に戻って処理を進める。一方、クエリーを受け取ってない場合（Ｎｏ）、ステップＳ００２に進み、異常通知を受け取ったか否かを判定する（ステップＳ００２）。異常通知を受け取った場合（Ｙｅｓ）、ステップＳ２００に進み、異常時の処理を行い（ステップＳ２００）、ステップＳ００１に戻って処理を進める。一方、異常通知を受け取っていない場合（Ｎｏ）、ステップＳ００３に進み、ジョブの終了通知を受け取ったか否かを判定する（ステップＳ００３）。ジョブの終了通知を受け取った場合（Ｙｅｓ）、ステップＳ３０１に進み、対象のジョブを処理中リストから削除（消去）し（ステップＳ３０１）、ステップＳ００１に戻って処理を進める。一方、ジョブの終了通知を受け取っていない場合（Ｎｏ）、ステップＳ００１に戻って処理を進める。

次に、図７は、単一外部プロセス２７００についてのクエリーを受け取った際の、単一外部プロセス２７００のステータスに応じたＬｏｃａｔｏｒ２５００の処理フローを示すフローチャートである。この処理は、図６のステップＳ００１でクエリーを受け取った場合のステップＳ１００の処理である。まず、単一外部プロセス２７００のステータスが「不在」であるか否かを判定する（ステップＳ１１０）。単一外部プロセス２７００のステータスが「不在」の場合（Ｙｅｓ）、ステップＳ１１１に進む。ここで、単一外部プロセス２７００のステータスが「不在」とは、単一外部プロセスが２７００起動されていない状態を示す。次に、Ｌｏｃａｔｏｒ２５００は、Ａｃｔｉｖａｔｏｒ２５５０に単一外部プロセス２７００の生成を依頼する（ステップＳ１１１）。すなわち、対象の単一外部プロセスを起動する。Ａｃｔｉｖａｔｏｒ２５５０は、単一外部プロセス２７００を起動すると、単一外部プロセス２７００のプロセスＩＤを取得し、Ｌｏｃａｔｏｒ２５００に単一外部プロセス２７００の起動が完了したことを通知する。次に、Ｌｏｃａｔｏｒ２５００は、この通知を受けると、対象の単一外部プロセス２７００のＥＰ Ｓｈｅｅｔのステータスを「処理可能」に更新（変更）し（ステップＳ１１２）、ステップＳ１２１進む。

ステップＳ１１０で、単一外部プロセス２７００のステータスが「不在」でない場合（Ｎｏ）、ステップＳ１２０に進む。そして、単一外部プロセス２７００のステータスが「処理可能」であるか否かを判定する（ステップＳ１２０）。単一外部プロセス２７００のステータスが「処理可能」である場合（Ｙｅｓ）、ステップＳ１２１に進む。Ｌｏｃａｔｏｒ２５００は、クエリーをしてきたＦｉｌｔｅｒ（ジョブの依頼主）をＥＰ Ｓｈｅｅｔの使用中リストに登録し（ステップＳ１２１）、ＦｉｌｔｅｒにＲｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅ（ジョブ依頼の許可）を送る（ステップＳ１２２）。なお、ＥＰ Ｓｈｅｅｔの使用中リストに登録する内容は、ＦｉｌｔｅｒのプロセスＩＤなど、Ｆｉｌｔｅｒを特定できる情報である。Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅには、コンポーネント（本実施形態では、単一外部プロセス２７００）の名前、サービスＩ／Ｆを示すＵＲＬとポート番号が格納されている。Ｆｉｌｔｅｒは、Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを受け取ると、単一外部プロセス２７００のサービスＩ／Ｆを利用して単一外部プロセス２７００にジョブを依頼することができる。

ステップＳ１２０で、単一外部プロセス２７００のステータスが「処理可能」でない場合（Ｎｏ）、ステップＳ１３１に進む。すなわち、単一外部プロセス２７００のステータスが「不在」と「処理可能」以外である場合、つまり「異常」であると判定される。そして、Ｌｏｃａｔｏｒ２５００は、他のＦｉｌｔｅｒから新たに依頼されるジョブをＥＰ Ｓｈｅｅｔの待機中リストに登録する（ステップＳ１３１）。このとき、Ｌｏｃａｔｏｒ２５００は、ジョブの依頼元のＦｉｌｔｅｒにＲｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを送信しないことで、依頼されたジョブを待機させる。

（正常時の処理）
図８は、Ｆｉｌｔｅｒ Ａ１（２４０１）が単一外部プロセス２７００を用いてジョブを処理する際のシーケンス図である。まず、Ｆｉｌｔｅｒ Ａ１（２４０１）は、Ｌｏｃａｔｏｒ２５００に使用したい単一外部プロセス２７００についてクエリーする（ステップＳ２０１０）。このとき、Ｌｏｃａｔｏｒ２５００は、必要に応じて単一外部プロセスを起動する処理を行う。次に、Ｌｏｃａｔｏｒ２５００は、保持するＥＰ Ｓｈｅｅｔの使用中リストにＦｉｌｔｅｒ Ａ１（２４０１）を登録する（ステップＳ１０１０）。そして、Ｌｏｃａｔｏｒ２５００は、Ｆｉｌｔｅｒ Ａ１（２４０１）からのクエリーに対し、単一外部プロセス２７００のアクセスポイントの情報を載せたＲｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを送る（ステップＳ１０２０）。

次に、Ｆｉｌｔｅｒ Ａ１２４０１は、単一外部プロセス２７００のアクセスポイントを取得すると、ジョブを単一外部プロセス２７００に依頼する（ステップＳ２０３０）。ここで、Ｆｉｌｔｅｒ Ａ１（２４０１）は、単一外部プロセス２７００にジョブを依頼する前に、後述する「リトライフラグ」が立っている場合、「リトライフラグ」を下ろす（ステップＳ２０２０）。なお、単一外部プロセス２７００に異常がない場合、リトライフラグは下りている。また、Ｆｉｌｔｅｒ Ａ１（２４０１）は、単一外部プロセス２７００にジョブを依頼する際、単一外部プロセス２７００での処理時間に制限を持たせるためのタイマーをスタートさせる。単一外部プロセス２７００での処理が時間内に正常終了すると、Ｆｉｌｔｅｒ Ａ１（２４０１）は、単一外部プロセス２７００から処理結果を受け取る（ステップＳ３０１０）。そして、Ｆｉｌｔｅｒ Ａ１（２４０１）は、Ｌｏｃａｔｏｒ２５００にＤｏｎｅ Ｍｅｓｓａｇｅを送信し（ステップＳ２０４０）、単一外部プロセス２７００を使用し終えたことを通知する。Ｆｉｌｔｅｒ Ａ１（２４０１）は、その後、次のＦｉｌｔｅｒまたはＪｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００へ結果を渡す。次に、Ｌｏｃａｔｏｒ２５００は、Ｆｉｌｔｅｒ Ａ１（２４０１）をＥＰ Ｓｈｅｅｔの使用中リストから削除する（ステップＳ１０３０）。

（単一外部プロセスでの異常の検出）
前述のＦｉｌｔｅｒ Ａ１（２４０１）がスタートさせたタイマーが一定時間を越えてタイムアウトした場合、Ｆｉｌｔｅｒ Ａ１（２４０１）は、単一外部プロセス２７００に異常が発生したと判定する。すなわち、処理中のジョブが処理完了することなく、一定時間が経過した場合に異常が発生したと判定する。Ｆｉｌｔｅｒ Ａ１（２４０１）は、Ｌｏｃａｔｏｒ２５００に異常を通知するＴｉｍｅｏｕｔ Ｍｅｓｓａｇｅを送り、制御プロセスであるＪｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００にも異常を通知する。Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００は、この異常通知を受けるとジョブの失敗をＰｒｏｘｙ２２００に伝える。

（リトライの処理）
図９は、Ｆｉｌｔｅｒ Ａ２（２４０２）が単一外部プロセス２７００でのジョブをリトライする場合のシーケンス図である。本実施形態では、Ｆｉｌｔｅｒ Ａ１（２４０１）のジョブにより単一外部プロセス２７００で異常が発生し、タイムアウトするまでの間にＦｉｌｔｅｒ Ａ２（２４０２）のジョブが依頼され、かつジョブの依頼後にタイムアウトした場合の流れを示す。本実施形態では、Ｆｉｌｔｅｒ Ａ１（２４０１）のジョブによって単一外部プロセス２７００で異常が発生したことにより、単一外部プロセス２７００を再起動し、Ｆｉｌｔｅｒ Ａ２（２４０２）のジョブをリトライする処理について説明する。

まず、Ｆｉｌｔｅｒ Ａ１（２４０１）は、タイムアウトしたと判定するとＴｉｍｅｏｕｔ ＭｅｓｓａｇｅをＬｏｃａｔｏｒ２５００に送信する（ステップＳ２１１１）。この時点では、Ｌｏｃａｔｏｒ２５００が保持するＥＰ Ｓｈｅｅｔの使用中リストには、Ｆｉｌｔｅｒ Ａ１（２４０１）とＦｉｌｔｅｒ Ａ２（２４０２）が登録されている。次に、Ｌｏｃａｔｏｒ２５００は、Ｔｉｍｅｏｕｔ Ｍｅｓｓａｇｅを受信すると、ＥＰ Ｓｈｅｅｔのステータスを「異常」に変更する（ステップＳ１１１０）。そして、Ｆｉｌｔｅｒ Ａ１（２４０１）をＥＰ Ｓｈｅｅｔの使用中リストから削除する（ステップＳ１１２０）。これは、タイムアウトをしたＦｉｌｔｅｒ Ａ１（２４０１）のジョブによって単一外部プロセス２７００が異常状態に陥った可能性が高いからである。次に、Ｌｏｃａｔｏｒ２５００は、使用中リストに残ったＦｉｌｔｅｒ（本実施形態では、Ｆｉｌｔｅｒ Ａ２（２４０２））宛てにＣａｕｔｉｏｎ Ｍｅｓｓａｇｅを送る（ステップＳ１１３０）。Ｃａｕｔｉｏｎ Ｍｅｓｓａｇｅは、単一外部プロセス２７００での異常を各Ｆｉｌｔｅｒに通知するものである。

Ｃａｕｔｉｏｎ Ｍｅｓｓａｇｅを受け取ったＦｉｌｔｅｒ Ａ２（２４０２）は、リトライフラグを立てる（ステップＳ２１２２）。リトライフラグは、そのＦｉｌｔｅｒが単一外部プロセス２７００に依頼したジョブがリトライの対象であるか否かを示すフラグである。リトライフラグが立っているＦｉｌｔｅｒ Ａ２（２４０２）は、ジョブをリトライする権利を有する。また、リトライフラグが立っている間、単一外部プロセス２７００は、再起動され（ステップＳ１１４０）、単一外部プロセス２７００からＦｉｌｔｅｒ Ａ２（２４０２）に対しエラー通知が送られる（ステップＳ３１１０）。これは、単一外部プロセス２７００で処理中だったジョブが強制的に中断されるためである。Ｆｉｌｔｅｒ Ａ２（２４０２）は、リトライフラグが立っている間、単一外部プロセス２７００のエラー通知を受け取っても何もしない。こうすることで、単一外部プロセス２７００が再起動するまでジョブを待機させることができる。

単一外部プロセス２７００の再起動後、Ｌｏｃａｔｏｒ２５００は、使用中リストに残ったＦｉｌｔｅｒ Ａ２（２４０２）にＲｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを送信しリトライを開始させる（ステップＳ１１５０）。そして、Ｆｉｌｔｅｒ Ａ２（２４０２）は、リトライフラグを下ろし（ステップＳ２１３２）、単一外部プロセス２７００にジョブを依頼する（ステップＳ２１４２）。ジョブが正常に処理されれば、単一外部プロセス２７００から処理結果がＦｉｌｔｅｒ Ａ２（２４０２）に送られる（ステップＳ３１２０）。そして、その後の処理は、正常時の処理と同様であり、Ｆｉｌｔｅｒ Ａ２（２４０２）は、Ｌｏｃａｔｏｒ２５００にＤｏｎｅ Ｍｅｓｓａｇｅを送信し（ステップＳ２１５２）、単一外部プロセス２７００を使用し終えたことを通知する。Ｆｉｌｔｅｒ Ａ２（２４０２）は、その後、次のＦｉｌｔｅｒまたはＪｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００へ結果を渡す。次に、Ｌｏｃａｔｏｒ２５００は、Ｆｉｌｔｅｒ Ａ２（２４０２）をＥＰ Ｓｈｅｅｔの使用中リストから削除する（ステップＳ１１６０）。

（ジョブの待機）
図１０は、Ｆｉｌｔｅｒ Ａ１（２４０１）がタイムアウトした直後にＦｉｌｔｅｒ Ａ３（２４０３）がＬｏｃａｔｏｒ２５００に単一外部プロセス２７００についてクエリーしてきたときの処理を示すシーケンス図である。あるＦｉｌｔｅｒでタイムアウトが発生した後にＬｏｃａｔｏｒ２５００が受け付けたジョブは、単一外部プロセス２７００が再起動するまで待機させられる。

まず、Ｆｉｌｔｅｒ Ａ１（２４０１）からＴｉｍｅｏｕｔ ＭｅｓｓａｇｅがＬｏｃａｔｏｒ２５００に送信されると（ステップＳ２２１１）、Ｌｏｃａｔｏｒ２５００は、ＥＰ Ｓｈｅｅｔのステータスを「異常」に変更する（ステップＳ１２１０）。前述の通り、ステータスが「異常」である場合、Ｌｏｃａｔｏｒ２５００は、他のＦｉｌｔｅｒから新たに依頼されるジョブをＥＰ Ｓｈｅｅｔの待機中リストに登録する。本実施形態では、Ｆｉｌｔｅｒ Ａ３（２４０３）から単一外部プロセスについてクエリーがされる（ステップＳ２２１３）。従って、Ｆｉｌｔｅｒ Ａ３（２４０３）は、Ｌｏｃａｔｏｒ２５００により、ＥＰ Ｓｈｅｅｔの待機中リストに登録される（ステップＳ１２２０）。次に、単一外部プロセス２７００が再起動される（ステップＳ１２３０）と、Ｌｏｃａｔｏｒ２５００は、Ｆｉｌｔｅｒ Ａ３（２４０３）をＥＰ Ｓｈｅｅｔの待機中リストから使用中リストに移す（ステップＳ１２４０）。そして、Ｌｏｃａｔｏｒ２５００は、ＥＰ Ｓｈｅｅｔのステータスを「処理可能」に変更し（ステップＳ１２５０）、ジョブを待機させるモードを解除する。使用中リストに移されたＦｉｌｔｅｒ Ａ３（２４０３）は、Ｌｏｃａｔｏｒ２５００からＲｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを受け取り（ステップＳ１２６０）、待機させていたジョブを、単一外部プロセス２７００に依頼する（ステップＳ２２２３）。

単一外部プロセス２７００で異常が発生したときの処理（図９および図１０に示す処理）は、図１１のようにまとめることができる。図１１は、図６のステップＳ００２で異常通知を受け取った場合のステップ２００の処理を示す。図１１に示す各ステップＳ２１０〜Ｓ２４０は、図９および図１０に示す処理と対応している。単一外部プロセス２７００で障害が発生した場合、まず。復旧処理中に単一外部プロセス２７００に依頼されるジョブを待機させる（ステップＳ２１０）。次に、単一外部プロセス２７００を再起動し（ステップＳ２２０）、障害に巻き込まれて失敗したジョブに対しては、単一外部プロセスでの処理をリトライする（ステップＳ２３０）。そして、ジョブの待機状態を解除する（ステップＳ２４０）。

以上、本実施形態によれば、複数ジョブの並列処理において、新たに障害に巻き込まれるジョブを無くし、単一外部プロセス２７００での障害で失敗する処理の数を最小限に抑えることが可能となる。

（第２実施形態）
本実施形態では、各Ｆｉｌｔｅｒと単一外部プロセス２７００間で、ストリーミング形式で変換データを転送する場合の障害の復旧方法について説明する。本実施形態の障害の復旧方法では、ジョブのリトライの過程で単一外部プロセス２７００の異常状態を引き起こしたジョブを特定する。

Ｆｉｌｔｅｒは、単一外部プロセス２７００にジョブを依頼する際、データをストリーミング形式で転送し、単一外部プロセス２７００は、受け取ったデータから順に変換処理を行う。単一外部プロセス２７００で異常が発生すると、Ｆｉｌｔｅｒからのデータの転送が進行しなくなる。これにより、Ｆｉｌｔｅｒは、第１実施形態と同様、タイムアウトによって単一外部プロセスの異常を検出することも可能であるが、データ転送の進行度をもとに単一外部プロセス２７００の異常を検出することも可能となる。例えば、転送済みのデータ転送量がある一定時間変化しなかった場合、単一外部プロセス２７００に異常があると判定できる。本実施形態では、異常を早期に検出するため、単一外部プロセス２７００の異常検出方法として後者の手法を採用する。

ここで、単一外部プロセス２７００の異常の発生原因となったジョブを特定する手法の概要について図１２を用いて説明する。単一外部プロセス２７００で複数のジョブが並列処理されている最中に単一外部プロセス２７００で異常が発生すると、処理中のジョブが同時に停止する。このとき、ジョブのタイムアウトによって単一外部プロセス２７００の異常状態を検出するのは、処理中であったジョブの中で最も古いジョブである。しかしながら、どのジョブが原因で異常が発生したのかをその場で特定することは難しい。例えば、図１２は、単一外部プロセス２７００に５つのＦｉｌｔｅｒからジョブがＪｏｂ１、Ｊｏｂ２、Ｊｏｂ３、Ｊｏｂ４、Ｊｏｂ５の順番に依頼され、処理が進行する場合の概要を示す図である。本実施形態では、Ｊｏｂ１、Ｊｏｂ２、Ｊｏｂ３が並列処理されている途中に、Ｊｏｂ２が原因で単一外部プロセス２７００に異常が発生したとする。Ｊｏｂ１とＪｏｂ３は、異常発生時にＪｏｂ２と共に処理が進行しなくなってしまう。この異常状態を検出するのは、上述のように、最も古いジョブであるＪｏｂ１である。ここで、Ｊｏｂ４は、単一外部プロセス２７００で異常が発生し、Ｊｏｂ１が異常を検出するまでの間に単一外部プロセス２７００に依頼されたものとする。また、Ｊｏｂ５は、Ｊｏｂ１が異常を検出した後に単一外部プロセス２７００に依頼されようとしているものとする。

本実施形態に係るジョブをリトライする場合の概要を図１３に示す。本実施形態では、リトライの対象となるのはＪｏｂ１が単一外部プロセス２７００の異常を検出した際に、単一外部プロセス２７００で処理をしていたジョブである。すなわち、Ｊｏｂ１、Ｊｏｂ２、Ｊｏｂ３、Ｊｏｂ４がリトライの対象となる。図１３では、実線の矢印がジョブの進行度合いを表し、実線の右端が丸いジョブは処理が正常終了したことを表す。また、それら実線の下に描かれた灰色の線はジョブの制限時間を表す。ジョブの制限時間とは、ジョブのデータ転送が滞ってからある一定時間後にタイムアウトするよう設定されている。ジョブのリトライは、二段階に分けることができ、第一段階では異常の原因特定手法を使い、原因特定後は第二段階として第１実施形態と同じ流れでリトライを行う。

図１４は、上記の一段階目の異常原因特定手法の処理を示すフローチャートである。本実施形態では、リトライの対象となるジョブを、開始時刻に差をつけながらリトライさせる。ジョブをリトライさせる場合の順番については、図１３に示すように、リトライ前のジョブが投入された順番でなく、ドキュメントのサイズやページ数などから決定するジョブのサイズに基づいて決まる順番であってよい。このとき、リトライ対象のジョブを依頼するＦｉｌｔｅｒは、前回の処理実行時に単一外部プロセス２７００に転送したデータサイズを記憶し、リトライ時のデータ転送量がそれを上回るかどうかを監視する。ここでリトライ時のデータ転送量が前回のそれを上回った場合、これは単一外部プロセス２７００の異常状態の原因となったジョブではないと判定する。まず、障害を引き起こしたジョブを特定する処理が開始されると（ステップＳ５００）、リトライ対象のジョブが複数ある場合、その１つを単一外部プロセス２７００に投入してリトライを開始する（ステップＳ６００）。次に、当該ジョブが異常の原因か否かを判定する（ステップＳ５１０）。すなわち、当該ジョブの転送量（進行度）がリトライ前の転送量（進行度）を超えたか否かを判定する。

当該ジョブの転送量がリトライ前の転送量を超えた場合（Ｙｅｓ）、すなわち、当該ジョブが異常の原因ではない場合、ステップＳ５２０に進み、リトライ対象のジョブが残っているか否かを判定する（ステップＳ５２０）。ジョブが残っている場合（Ｙｅｓ）、ステップＳ６００に戻って、次のジョブのリトライを開始する。一方、ジョブが残っていない場合（Ｎｏ）、処理を終了する。ここで注意したいのは、ジョブのリトライが排他処理ではないという点である。

ステップＳ５１０で、当該ジョブの転送量がリトライ前の転送量を超えない場合（Ｎｏ）、すなわち、リトライ時のデータ転送量が前回のそれを上回ることができずデータ転送が停滞した（当該ジョブが異常の原因である）場合、ステップＳ７００に進む。そして、異常の原因であるジョブが特定されたので、後述の図１８に示す処理を行って（ステップＳ７００）、処理を終了する。

ここで、図１４に示す処理を図１３に適用する場合について説明する。図１３において、ジョブのリトライは、Ｊｏｂ４、Ｊｏｂ３、Ｊｏｂ２、Ｊｏｂ１の順に行われている。なお、リトライするジョブの順番については後述する。まず、Ｊｏｂ４のリトライを開始する。ここで、Ｊｏｂ４は、前回の処理では単一外部プロセス２７００で異常が発生した後に投入されたので、前回はデータ転送が全く進んでいないことになる。従って、リトライを開始し、データ転送が進み始めた時点で、リトライ前の転送量を超えることとなるので、Ｊｏｂ４は、単一外部プロセス２７００の異常の原因ではないと判定され、次のＪｏｂ３のリトライが始まる。Ｊｏｂ３がリトライで前回の処理におけるデータ転送量を超えると、異常の原因でないと判定されるので、次のＪｏｂ２のリトライが開始される。図１３では、Ｊｏｂ４とＪｏｂ３は、順調に処理が進み正常に終了する。しかしながら、本実施形態では、Ｊｏｂ２が単一外部プロセス２７００における異常状態の原因であるため、Ｊｏｂ２は、異常発生時のデータ転送量まで到達するとそれ以上データ転送が進まなくなり、結果としてデータの転送量が前回の転送量を上らない。また、Ｊｏｂ２のデータ転送が一定時間滞るとＪｏｂ２がタイムアウトする。

以上により、単一外部プロセス２７００での異常の原因がＪｏｂ２であると特定される。ここから、リトライは、第二段階、すなわち、第１実施形態と同じリトライ処理が行われる。具体的には、単一外部プロセス２７００は、再起動され、リトライの順番を待っていたＪｏｂ１のリトライとＪｏｂ５の待機状態を解除する処理を行う。なお、Ｊｏｂ２が異常の原因であったと特定された時点で、Ｊｏｂ３やＪｏｂ４の処理が終了していなかった場合は、第二段階のリトライでＪｏｂ１、Ｊｏｂ３、Ｊｏｂ４の３つのジョブをリトライする。

次に、図１４に示す処理の後、システムの障害復の旧方法について説明する。まず、第１実施形態とは異なる処理について説明する。図８において、ステップＳ２０１０で、ＦｉｌｔｅｒがＬｏｃａｔｏｒ２５００に単一プロセスについてクエリーする際、依頼したいジョブの変換対象となるドキュメントの大きさをＬｏｃａｔｏｒ２５００に情報として提供する。提供する情報は、例えば、ドキュメントのデータサイズでよく、ページ数でもよい。これを受けて、ステップＳ１０１０で、Ｌｏｃａｔｏｒ２５００は、ＥＰ Ｓｈｅｅｔの使用中リストにクエリー元であるＦｉｌｔｅｒと変換対象ドキュメントの大きさを登録する。

なお、本実施形態では、Ｌｏｃａｔｏｒ２５００が管理するＥＰ Ｓｈｅｅｔの単一外部プロセス２７００のステータスに「リトライ」を追加する。すなわち、Ｌｏｃａｔｏｒ２５００は、「不在」「処理可能」「異常」「リトライ」の４種類のステータスで単一外部プロセス２７００を管理する。また、ＥＰ Ｓｈｅｅｔで管理するリストをひとつ追加し、これを「リトライリスト」と呼ぶ。リトライリストは、リトライするジョブの依頼元であるＦｉｌｔｅｒのリストである。

本実施形態では、Ｆｉｌｔｅｒは、単一外部プロセス２７００の異常を検出したとき、Ｌｏｃａｔｏｒ２５００にＴｉｍｅｏｕｔ Ｍｅｓｓａｇｅを送信し異常を通知するが、この時、Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００には異常通知をしない。これは、異常を検出したＦｉｌｔｅｒにもリトライの機会を与えるためである。ただし、リトライ中に単一外部プロセス２７００の異常を検出したＦｉｌｔｅｒは、Ｌｏｃａｔｏｒ２５００とＪｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００の両者に異常を通知する。以上が第１実施形態とは異なる処理である。

次に、図１５〜１８を用いて、あるＦｉｌｔｅｒからＴｉｍｅｏｕｔ ＭｅｓｓａｇｅがＬｏｃａｔｏｒ２５００に届いた後の障害の復旧処理について説明する。なお、図１５〜１８は、ジョブのリトライに関するＬｏｃａｔｏｒ２５００の処理を示すフローチャートである。図１５は、リトライ対象のＦｉｌｔｅｒの処理を示すフローチャートである。図１６は、Ｌｏｃａｔｏｒ２５００がＦｉｌｔｅｒからＴｉｍｅｏｕｔ Ｍｅｓｓａｇｅを受け取り、リトライを開始するまでの処理を示すフローチャートである。図１７は、リトライ対象の次のジョブのリトライ処理を行う際のフローチャートである。図１８は、障害を引き起こしたジョブが特定された際の処理を示すフローチャートである。

まず、図１６で、Ｌｏｃａｔｏｒ２５００は、ＥＰ Ｓｈｅｅｔのステータスを「異常」に変更する（ステップＳ４０１）。そして、ＥＰ Ｓｈｅｅｔの使用中リストに登録されている全てのＦｉｌｔｅｒ（ジョブの依頼主）にＣａｕｔｉｏｎ Ｍｅｓｓａｇｅ（異常）を送信する（ステップＳ４０２）。次に、図１５で、Ｃａｕｔｉｏｎ Ｍｅｓｓａｇｅを受け取ったＦｉｌｔｅｒは、リトライフラグを立て（ステップＳ３０１）、単一外部プロセスに依頼していたジョブのデータをどこまで転送したかを記録する（ステップＳ３０２）。ここで、図１６で、Ｌｏｃａｔｏｒ２５００は、単一外部プロセス２７００を、Ａｃｔｉｖａｔｏｒ２５５０を通じて再起動する（ステップＳ４０３）。単一外部プロセス２７００が再起動したらＬｏｃａｔｏｒ２５００は、ＥＰ Ｓｈｅｅｔのステータスを「リトライ」に変更する（ステップＳ４０４）。

次に、Ｌｏｃａｔｏｒ２５００は、ＥＰ Ｓｈｅｅｔの使用中リストに登録された情報を、ドキュメントのサイズが昇順になるよう並べ替えて、ＥＰ Ｓｈｅｅｔのリトライリストに登録する（ステップＳ４０５）。なお、リトライリストに登録したＦｉｌｔｅｒの情報は、使用中リストから削除する。ここで、ジョブを並べ替えたのはリトライをドキュメントの大きさが小さいものから順に行うためである。すなわち、処理対象のドキュメントが小さいジョブの方がデータ転送や変換処理の進行が早く、そのジョブが単一外部プロセス２７００の異常の原因であるか否かを早く突き止められる可能性が高いからである。また、リトライリストには、ドキュメントのサイズが昇順になるよう並べられている。従って、Ｌｏｃａｔｏｒ２５００は、図１７に示す次のジョブのリトライを開始する場合（ステップＳ６００）、リトライリストの先頭にあるジョブから順に対象のＦｉｌｔｅｒにＲｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを送信する（ステップＳ６０１）。そして、Ｌｏｃａｔｏｒ２５００は、Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを送ったＦｉｌｔｅｒの情報をリトライリストから使用中リストに移し（ステップＳ６０２）、リトライするジョブの順番とリトライ中のジョブを管理する。

次に、図１５で、Ｒｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅ（ジョブ依頼の許可）を受信したＦｉｌｔｅｒは、単一外部プロセス２７００に中断されたジョブを依頼し（ステップＳ３０３）、リトライを開始する。次に、Ｆｉｌｔｅｒは、現在処理中（再処理中）の単一外部プロセス２７００に転送するジョブのデータ転送量（進行度）が、ステップＳ３０２で記録したデータ転送量を超えるか否かを判定する（ステップＳ３０４）。データ転送量がステップＳ３０２で記録した転送量を超えた場合（Ｙｅｓ）、Ｆｉｌｔｅｒは、依頼したジョブがリトライ前の転送量（進行度）を超えることを示すＥｘｃｅｅｄ ＭｅｓｓａｇｅをＬｏｃａｔｏｒ２５００に送信する（ステップＳ３０５）。

そして、Ｌｏｃａｔｏｒ２５００は、図１４に示すように、Ｅｘｃｅｅｄ Ｍｅｓｓａｇｅを受け取るとＥＰ Ｓｈｅｅｔのリトライリストを参照する（ステップＳ５２０）。そして、リトライ対象のジョブが残っている場合、リトライ対象である次のＦｉｌｔｅｒにＲｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを送る（ステップＳ６００）。ステップＳ５２０でリトライリストが空であれば（リトライ対象のジョブが残っていない場合）、異常の原因となったジョブは特定できなかったが、リトライですべてのジョブが成功したということになる。

一方、ステップＳ３０４で、データ転送が一定時間滞る場合、すなわち、前回ジョブのデータ転送量がステップＳ３０２で記録したデータ転送量を超える場合（Ｎｏ）、ステップＳ３１５に進む。この場合、Ｆｉｌｔｅｒは、単一外部プロセス２７００が異常状態にあると判定し、Ｌｏｃａｔｏｒ２５００にＴｉｍｅｏｕｔ Ｍｅｓｓａｇｅを送信する（ステップＳ３１５）。次に、Ｆｉｌｔｅｒは、Ｊｏｂ Ｃｏｎｔｒｏｌｌｅｒ２３００にも異常を通知する（ステップＳ３１６）。そして、Ｌｏｃａｔｏｒ２５００は、Ｔｉｍｅｏｕｔ Ｍｅｓｓａｇｅを受信すると、単一外部プロセス２７００の異常を引き起こしたのは、最後にＲｅｓｐｏｎｓｅ Ｍｅｓｓａｇｅを送った先のＦｉｌｔｅｒのジョブである判定する（ステップＳ７００）。そこで、Ｌｏｃａｔｏｒ２５００は、これをリトライ対象外のＦｉｌｔｅｒとし、図１８の処理に移る。Ｌｏｃａｔｏｒ２５００は、図９に示す単一外部プロセス２７００の再起動のステップＳ２２０を行う。次に、Ｌｏｃａｔｏｒ２５００は、ＥＰ Ｓｈｅｅｔのリトライリストに登録されているＦｉｌｔｅｒを使用中リストに移し（ステップＳ７１０）、実施形態１と同様に、図９に示す残りのジョブのリトライを実行する（ステップＳ２３０）。

なお、異常の原因となるジョブを特定できた場合も、リトライ対象のジョブがすべて処理に成功した場合も、最後に待機中のジョブの待機状態を解除する処理を行い（ステップＳ２４０）、システムを正常状態に戻す。

以上、本実施形態によれば、異常の原因となるジョブを特定することで、複数ジョブの並列処理において、新たに障害に巻き込まれるジョブを無くし、単一外部プロセス２７００での障害で失敗する処理の数を最小限に抑えることが可能となる。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。
ここで、本発明は、上述した実施形態の機能を実現する１以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の一つである。また、そのプログラムは、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給され、そのシステム或いは装置の１以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の一つとして、さらにそのプログラム自体、あるいは該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

また、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (10)

1. 単一プロセスを共有して複数のジョブの並列処理を行う情報処理システムであって、
   前記単一プロセスにおいてジョブを処理中に発生した異常を検出する検出手段と、
   前記検出手段により前記異常が検出された場合に前記単一のプロセスに依頼された新たなジョブを待機させる待機手段と、
   前記単一プロセスを再起動させる起動手段と、
   前記単一プロセスの再起動後に前記異常の発生時に処理中であったジョブを前記単一プロセスに再処理させる処理手段と
   を備える
   ことを特徴とする情報処理システム。
2. 前記検出手段は、処理中のジョブが処理完了することなく一定時間が経過した場合、前記処理が開始された時間が最も早いジョブが前記異常の発生原因であると特定し、
   前記処理手段は、前記異常の発生原因であるジョブを除いて、処理中であったジョブを前記単一プロセスに再処理させる
   ことを特徴とする請求項１に記載の情報処理システム。
3. 前記処理手段は、前記異常の発生時に処理中であったジョブを前記ジョブのサイズに基づく順番で再処理させ、
   前記検出手段は、前記再処理するジョブの進行度に基づいて前記異常の発生原因のジョブを特定する
   ことを特徴とする請求項１に記載の情報処理システム。
4. 前記処理手段は、前記ジョブのサイズが小さいジョブから順番に、それぞれのジョブを再処理させる
   ことを特徴とする請求項３に記載の情報処理システム。
5. 前記検出手段は、前記異常を検出する前のジョブの進行度を記憶し、前記再処理中のジョブの進行度と比較することで前記異常の発生原因のジョブを特定する
   ことを特徴とする請求項３または４に記載の情報処理システム。
6. 前記検出手段は、前記再処理中のジョブの進行度が前記異常を検出する前のジョブの進行度を超えない場合、該ジョブが異常の発生原因であると特定する
   ことを特徴とする請求項５に記載の情報処理システム。
7. 前記待機手段は、前記処理手段が前記ジョブの再処理を完了した後に、前記新たなジョブの待機を解除し、
   前記処理手段は、前記新たなジョブを単一プロセスに処理させる
   ことを特徴とする請求項１〜６のいずれか１項に記載の情報処理システム。
8. 単一プロセスを共有して複数のジョブの並列処理を行う情報処理装置であって、
   前記単一プロセスにおいてジョブを処理中に発生した異常を検出する検出手段と、
   前記検出手段により前記異常が検出された場合に前記単一のプロセスに依頼された新たなジョブを待機させる待機手段と、
   前記単一プロセスを再起動させる起動手段と、
   前記単一プロセスの再起動後に前記異常の発生時に処理中であったジョブを前記単一プロセスに再処理させる処理手段と
   を備える
   ことを特徴とする情報処理装置。
9. 単一プロセスを共有して複数のジョブの並列処理を行う情報処理装置の制御方法であって、
   前記単一プロセスにおいてジョブを処理中に発生した異常を検出する検出工程と、
   前記検出手段により前記異常が検出された場合に前記単一のプロセスに依頼された新たなジョブを待機させる待機工程と、
   前記単一プロセスを再起動させる起動工程と、
   前記単一プロセスの再起動後に前記異常の発生時に処理中であったジョブを前記単一プロセスに再処理させる処理工程と
   を有する
   ことを特徴とする情報処理装置の制御方法。
10. 請求項１〜７のいずれか１項に記載の情報処理システムの手段としてコンピュータに機能させることを特徴とするプログラム。

Images