(57)【要約】【課題】要求をキューに格納された順に実行するクライアントサーバシステムにおいて、阻害要求を受け付けたときにおいても、処理効率の低下を抑制すること。【解決手段】クライアント端末１の端末処理部が発行した要求を、サーバ装置２のスケジューラの制御に従って、サーバ装置２のサーバ処理部が実行するクライアントサーバシステムにおける要求制御方法であって、サーバ装置２の阻害要求管理部３８が、サーバ処理部の実行結果としてのエラー履歴をもとにエラーが頻発する阻害要求を認定し、サーバ装置２のキュー要求制御部３３が、エンキューおよびデキュー対象の各要求について、その要求が阻害要求に合致するときには、その合致する阻害要求を阻害要求一時格納部に退避する。【選択図】図２
2009129376.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末の端末処理部が発行した要求を、サーバ装置のスケジューラの制御に従って、前記サーバ装置のサーバ処理部が実行するクライアントサーバシステムにおける要求制御方法であって、
前記サーバ装置の前記スケジューラは、前記端末処理部から受け付けた要求を前記サーバ装置のキューにエンキューするとともに、前記キュー内の要求をデキューして前記サーバ処理部に実行させるキュー要求制御部と、前記サーバ処理部が実行してエラーが頻発する要求を阻害要求として管理する阻害要求管理部と、を有し、
前記阻害要求管理部は、
前記サーバ処理部の実行結果としてのエラーをキューエラー履歴記憶部に所定の阻害要求特定情報ごとに記録し、
記録されたエラー履歴が所定の阻害判定条件を満たしたときに、そのエラー履歴に関する阻害要求特定情報に合致する要求を阻害要求と認定して、その阻害要求特定情報を阻害要求管理記憶部に記録し、
前記阻害要求管理記憶部に記録された阻害要求について、所定の阻害判定条件を満たさなくなったときに、その阻害要求特定情報を前記阻害要求管理記憶部から削除することにより阻害要求を解除し、
前記キュー要求制御部は、
エンキューおよびデキュー対象の各要求について、その要求が前記阻害要求管理記憶部に記録された阻害要求特定情報に合致するときには、その合致する阻害要求を阻害要求一時格納部に退避し、
前記阻害要求管理部が阻害要求を解除した後、前記阻害要求一時格納部に退避されていた要求を、前記キューにエンキューすることで、阻害要求を復帰することを特徴とする
要求制御方法。
【請求項２】
前記キュー要求制御部は、要求を、前記キューにエンキューするときに、１つの要求を複数の前記キューに複製して、それぞれの複製された要求を、それぞれの前記キューにエンキューすることを特徴とする
請求項１に記載の要求制御方法。
【請求項３】
前記阻害要求管理部は、さらに、自装置の前記阻害要求管理記憶部と、他装置の前記阻害要求管理記憶部と、の内容を互いに共有することを特徴とする
請求項１または請求項２に記載の要求制御方法。
【請求項４】
前記キュー要求制御部は、要求の格納量が少ない前記キューを、阻害要求の復帰先となる前記キューとして特定することを特徴とする
請求項１ないし請求項３のいずれか１項に記載の要求制御方法。
【請求項５】
前記キュー要求制御部は、退避前に阻害要求がアクセスした前記キューを、阻害要求の復帰先となる前記キューとして特定することを特徴とする
請求項１ないし請求項３のいずれか１項に記載の要求制御方法。
【請求項６】
前記サーバ装置は、１つの物理計算機内に１つ以上構築された仮想計算機として構成され、
前記キュー要求制御部は、阻害要求の格納されている前記阻害要求一時格納部を有する前記サーバ装置から見て、別の物理計算機内の前記キューを、阻害要求の復帰先となる前記キューとして特定することを特徴とする
請求項１ないし請求項３のいずれか１項に記載の要求制御方法。
【請求項７】
前記阻害要求管理部は、所定期間の間復帰しない阻害要求の処理を中断し、その中断した阻害要求の発行元に実行の中止を通知することを特徴とする
請求項１ないし請求項６のいずれか１項に記載の要求制御方法。
【請求項８】
前記阻害要求管理部は、阻害要求特定情報として、要求の発行元の前記クライアント端末の前記端末処理部を示す識別子を用いることを特徴とする
請求項１ないし請求項７のいずれか１項に記載の要求制御方法。
【請求項９】
前記阻害要求管理部は、阻害要求特定情報として、要求の発行元の前記クライアント端末を示す識別子を用いることを特徴とする
請求項１ないし請求項７のいずれか１項に記載の要求制御方法。
【請求項１０】
請求項１ないし請求項９のいずれか１項に記載の要求制御方法を、コンピュータに実行させるための要求制御プログラム。
【請求項１１】
クライアント端末の端末処理部が発行した要求を、サーバ装置のスケジューラの制御に従って、前記サーバ装置のサーバ処理部が実行するクライアントサーバシステムに用いられるサーバ装置であって、
前記サーバ装置の前記スケジューラは、前記端末処理部から受け付けた要求を前記サーバ装置のキューにエンキューするとともに、前記キュー内の要求をデキューして前記サーバ処理部に実行させるキュー要求制御部と、前記サーバ処理部が実行してエラーが頻発する要求を阻害要求として管理する阻害要求管理部と、を有し、
前記阻害要求管理部は、
前記サーバ処理部の実行結果としてのエラーをキューエラー履歴記憶部に所定の阻害要求特定情報ごとに記録し、
記録されたエラー履歴が所定の阻害判定条件を満たしたときに、そのエラー履歴に関する阻害要求特定情報に合致する要求を阻害要求と認定して、その阻害要求特定情報を阻害要求管理記憶部に記録し、
前記阻害要求管理記憶部に記録された阻害要求について、所定の阻害判定条件を満たさなくなったときに、その阻害要求特定情報を前記阻害要求管理記憶部から削除することにより阻害要求を解除し、
前記キュー要求制御部は、
エンキューおよびデキュー対象の各要求について、その要求が前記阻害要求管理記憶部に記録された阻害要求特定情報に合致するときには、その合致する阻害要求を阻害要求一時格納部に退避し、
前記阻害要求管理部が阻害要求を解除した後、前記阻害要求一時格納部に退避されていた要求を、前記キューにエンキューすることで、阻害要求を復帰することを特徴とする
サーバ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントサーバシステムにおける要求制御方法、要求制御プログラム、および、サーバ装置に関するものである。
【背景技術】
【０００２】
クライアントサーバシステムにおけるサーバは、クライアントからの要求を受け付けて、処理を行い、その結果をクライアントに返信する。特定のサーバに要求が集中するのを防ぐため、特許文献１に開示されたように、クライアントとサーバとの間にキュー（queue）を設け、受け付けた要求をそのキューに一時的に保持する負荷分散手段（load balancing）がある。
【０００３】
キューとは、先着順（ＦＩＦＯ：First In, First Out）に、データを処理するためのデータ構造であり、キューの末尾にデータを入れることをエンキュー（Enqueue）、キューの先頭からデータを取り出すことをデキュー（Dequeue）と呼ぶ。特許文献１は、クライアントからの要求を負荷分散手段を通じて負荷の最も低いキューに割り当て、そのキューが他のキューに要求を複製する旨が、開示されている。
【特許文献１】特開２０００−５６９９６号公報
【特許文献２】特開２００６−１４６６７８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
クライアントからの要求は、サーバ側で処理された結果としてエラーが無い正常な要求と、サーバ側で処理された結果としてエラーが発生してしまう異常な要求と、に分類される。そして、エラーが多く発生した異常な要求は、実行の度に他の要求の実行を阻害するため、以下、阻害要求と呼ぶことにする。
【０００５】
サーバで実行待ちの要求は、阻害要求も含めてキューに先着順に順次入れられる。よって、阻害要求の後にキューに入れられている正常な要求は、キューの前方に存在する阻害要求のエラーが発生する可能性が高いにもかかわらず、その阻害要求のエラーの発生を待たされてから実行されるので、無駄な待ち時間を強いられる。さらに、エラーが発生した阻害要求は、再度キューに入れられることもあり、そのときには、無駄な待ち時間が繰り返し発生する。
【０００６】
つまり、阻害要求がキューに滞留してしまうことで、キューの許容量に対する要求の格納量が大きくなってしまい、キューの空き容量が減少する。その結果、新たに発生した正常な要求は、キューの前方に滞留している阻害要求のため、キューに入らなくなってしまう。よって、サーバ側は、正常な要求であるにもかかわらず、新たに発生した要求の処理を断念せざるを得ず、処理効率が著しく低下してしまう。
【０００７】
さらに、特許文献１に記載の負荷分散手段を通じて負荷分散をすると、１つの要求が、正常な要求か阻害要求かにかかわらず複数のキューに複製されてしまうため、阻害要求が影響する低効率化の範囲は、広がってしまう。
【０００８】
本発明の目的は、前記の問題点に鑑み、要求をキューに格納された順に実行するクライアントサーバシステムにおいて、阻害要求を受け付けたときにおいても、処理効率の低下を抑制することである。
【課題を解決するための手段】
【０００９】
前記課題を解決するため、本発明は、クライアント端末の端末処理部が発行した要求を、サーバ装置のスケジューラの制御に従って、前記サーバ装置のサーバ処理部が実行するクライアントサーバシステムにおける要求制御方法であって、
前記サーバ装置の前記スケジューラが、前記端末処理部から受け付けた要求を前記サーバ装置のキューにエンキューするとともに、前記キュー内の要求をデキューして前記サーバ処理部に実行させるキュー要求制御部と、前記サーバ処理部が実行してエラーが頻発する要求を阻害要求として管理する阻害要求管理部と、を有し、
前記阻害要求管理部が、
前記サーバ処理部の実行結果としてのエラーをキューエラー履歴記憶部に所定の阻害要求特定情報ごとに記録し、
記録されたエラー履歴が所定の阻害判定条件を満たしたときに、そのエラー履歴に関する阻害要求特定情報に合致する要求を阻害要求と認定して、その阻害要求特定情報を阻害要求管理記憶部に記録し、
前記阻害要求管理記憶部に記録された阻害要求について、所定の阻害判定条件を満たさなくなったときに、その阻害要求特定情報を前記阻害要求管理記憶部から削除することにより阻害要求を解除し、
前記キュー要求制御部が、
エンキューおよびデキュー対象の各要求について、その要求が前記阻害要求管理記憶部に記録された阻害要求特定情報に合致するときには、その合致する阻害要求を阻害要求一時格納部に退避し、
前記阻害要求管理部が阻害要求を解除した後、前記阻害要求一時格納部に退避されていた要求を、前記キューにエンキューすることで、阻害要求を復帰することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１０】
本発明によれば、要求をキューに格納された順に実行するクライアントサーバシステムにおいて、阻害要求を受け付けたときにおいても、処理効率の低下を抑制することができる。
【発明を実施するための最良の形態】
【００１１】
以下、図面を用いて本発明を実施するための最良の形態を説明する。
図１は、クライアントサーバシステムの構成図である。クライアントサーバシステムは、要求を発行する１台以上のクライアント端末１と、クライアント端末１からの要求を受け付けて実行する１台以上のサーバ装置２と、がネットワーク９を介して接続されて構成されている。
【００１２】
サーバ装置２は、演算処理を行う際に用いられる記憶手段としての主記憶装置６６と、前記演算処理を行うＣＰＵ（Central Processing Unit）６１とを少なくとも備えるコンピュータとして構成される。なお、主記憶装置６６は、ＲＡＭ（Random Access Memory）などにより構成される。演算処理は、ＣＰＵ６１が、主記憶装置６６上のプログラムを実行することで、実現される。
【００１３】
２次記憶装置６４は、主記憶装置６６上に読み込まれるプログラムおよびそのプログラムが処理するデータを格納する。ＣＰＵ６１は、さらに、インタフェースとして、画面表示を行うためのディスプレイ６２、データ入力を行うためのキーボード６３、および、他装置との通信を行うためのネットワークインタフェース６５を制御する。
【００１４】
クライアント端末１は、端末処理部１１を１つ以上実行させる。端末処理部１１は、クライアントサーバシステムにおけるクライアントの機能を実現するためのプログラムを実行したプロセスまたはスレッドであり、他の端末処理部１１と区別するための端末処理部ＩＤが割り当てられている。
【００１５】
サーバ装置２の主記憶装置６６は、端末処理部１１からの要求を効率的に処理するためにスケジュールするスケジューラ３と、クライアントサーバシステムにおけるサーバの機能を実現し、スケジューラ３に従った順序で端末処理部１１からの要求を実行するサーバ処理部２１と、を有する。サーバ処理部２１は、実行結果が正常である（エラーが発生しない）ときには、その結果を要求元の端末処理部１１に応答する。
【００１６】
スケジューラ３は、キュー３１と、キューエラー履歴テーブル３２と、キュー要求制御部３３と、キュー格納量管理テーブル３４と、キュー格納量管理部３５と、阻害要求一時格納部３６と、阻害要求管理テーブル３７と、阻害要求管理部３８と、を有する。これらの各処理部および各記憶部の詳細は、図２の説明において後記する。
【００１７】
図２は、図１のクライアントサーバシステムの機能概要図である。
【００１８】
キュー３１は、１台のサーバ装置２内に１つ以上配置され、端末処理部１１からの要求を先着順で一時的に格納する。キュー要求制御部３３は、端末処理部１１から受け付けた要求をキュー３１にエンキューするとともに、そのエンキューした要求をサーバ処理部２１で実行させるためにデキューする。なお、キュー要求制御部３３は、要求をサーバ処理部２１で実行させたり、既に実行されている要求を中断したりするために、例えば特許文献２で記載されたような制御メッセージを、サーバ処理部２１に対して通知する。
【００１９】
【表１】
2009129376.tif 000003
【００２０】
表１のキューエラー履歴テーブル３２は、キュー３１ごとに、そのキュー３１内の要求がサーバ処理部２１で実行されてエラーとなったときに、その旨の履歴を記録する。キューエラー履歴テーブル３２は、自装置内のキュー３１を特定するキューＩＤと、エラーとなった要求の発行元である端末処理部ＩＤと、発生したエラーのエラー種別と、発生したエラーのエラー発生履歴と、エラー発生履歴と照合されることでエントリが阻害要求か否かを判定するための阻害判定閾値と、を対応づけて管理する。
【００２１】
例えば、キューＩＤ「Ｑ１」に格納されていた端末処理部ＩＤ「ＣＰ１」からの要求のうち、エラー種別「タイムアウト」が発生したエラーのエラー発生履歴は、「11:00、13:00、14:00」という各時刻に発生した合計３回である。そして、このエラー発生履歴と、阻害判定閾値「２時間以内に２回発生」とを照合すると、現在時刻が「14:30」のときには、時間「12:30〜14:30」内には、エラーが２回発生「13:00、14:00」しているので、閾値「２回」以上で阻害要求と認定される。一方、現在時刻が「15:30」のときには、時間「13:30〜15:30」内には、エラーが１回発生「14:00」しているので、閾値「２回」未満で阻害要求が解除される。
【００２２】
【表２】
2009129376.tif 000004
【００２３】
表２のキュー格納量管理テーブル３４は、キュー３１に格納されている要求の格納量をキュー３１ごとに管理する。キュー格納量管理テーブル３４は、サーバ装置２を特定するためのサーバ装置ＩＤと、そのサーバ装置ＩＤのサーバ装置２内に存在するキュー３１のキューＩＤと、キューＩＤのキュー３１に格納されている要求のキュー格納量と、を対応づけて管理する。
【００２４】
例えば、サーバ装置ＩＤ「ＳＶ１」のキューＩＤ「Ｑ１，Ｑ２」と、サーバ装置ＩＤ「ＳＶ２」のキューＩＤ「Ｑ１」と、から特定される３つのキュー３１のうち、一番空いているキュー３１は、サーバ装置ＩＤ「ＳＶ１」のキューＩＤ「Ｑ１」のキュー３１である。よって、このキュー３１は、負荷分散により優先的に要求がエンキューされる可能性が高い。
【００２５】
キュー格納量管理部３５は、自装置のキュー３１の格納量を更新するとともに、自装置のキュー３１の格納量と、他装置のキュー３１の格納量とを互いに内容交換（共有）することで、クライアントサーバシステムに存在するキュー３１のうち、どのキュー３１が混んでいるかを特定する。
【００２６】
阻害要求管理部３８は、キューエラー履歴テーブル３２を参照して、サーバ処理部２１で実行された要求のうち、今後も実行エラーとなって他の要求の処理を阻害する可能性のある阻害要求を特定する。阻害要求一時格納部３６は、阻害要求管理部３８により阻害要求と特定された要求を、キュー３１からデキューして一時的に格納することで、他の要求の実行を妨げないようにする。さらに、阻害要求管理部３８は、既に特定した阻害要求について、時間経過により阻害要求の要件を満たさなくなったものを、阻害要求から解除する。解除された阻害要求は、自装置または他装置のキュー３１に復帰される。
【００２７】
【表３】
2009129376.tif 000005
【００２８】
表３の阻害要求管理テーブル３７は、阻害要求管理部３８により阻害要求と特定された要求に関する情報を管理する。阻害要求管理テーブル３７は、キューエラー履歴テーブル３２と同じ形式の「キューＩＤ、端末処理部ＩＤ、エラー種別」と、阻害要求一時格納部３６に格納されている阻害要求を示す阻害要求リストと、を対応づけて管理する。
【００２９】
例えば、キューＩＤ「Ｑ１」にエンキューされる、または、キューＩＤ「Ｑ１」からデキューされた端末処理部ＩＤ「ＣＰ１」から要求された阻害要求は、エラー種別「タイムアウト」のエラーが頻発したために阻害要求と認定された。よって、阻害要求一時格納部３６には、阻害要求リスト「Ｒ１１，Ｒ１２，Ｒ１３」という３つの阻害要求が、それぞれ退避されている。
【００３０】
阻害要求管理部３８は、自装置の阻害要求管理テーブル３７を更新するとともに、自装置の阻害要求管理テーブル３７と、他装置の阻害要求管理テーブル３７とを互いに内容交換（共有）することで、他装置では実行したが自装置ではまだ実行していない阻害要求を、自装置での実行前に退避することができる。
【００３１】
図３Ａ〜図５Ｂは、図１、図２に示したクライアントサーバシステムの動作の概要を説明するための説明図である。以下、図３Ａ、図３Ｂ、図４Ａ、図４Ｂ、図５Ａ、図５Ｂの順に説明を行う。これにより、阻害要求の判定、退避、および、復帰が明確化される。
【００３２】
図３Ａは、端末処理部ＩＤ「ＣＰ１」からの要求「Ｒ１１」に、実行エラーが発生した旨を示す。キュー３１は、要求を受け付けると、先着順に左からエンキューし、右へとデキューする。キュー３１には、３つの要求「Ｒ１１，Ｒ１２，Ｒ２１」が入っている。図中の楕円形で示される要求「Ｒ１１（ＣＰ１）」は、Ｒ１１という要求が端末処理部ＩＤ「ＣＰ１」から発行されたことを示している。
【００３３】
サーバ処理部２１は、要求「Ｒ１１」を実行したが、エラーが発生してしまう。キューエラー履歴テーブル３２は、今回発生したエラー１回分を、既に発生したエラー２回分と合計する。これにより、端末処理部ＩＤ「ＣＰ１」に関するエラーは３回となり、阻害判定閾値の３回以上に該当するので阻害要求と認定される。認定された阻害要求は、阻害要求管理テーブル３７に登録される。
【００３４】
図３Ｂは、図３Ａの後に、阻害要求と判定されたＣＰ１の要求「Ｒ１１」を、阻害要求として退避する旨を示す。キュー３１からは、阻害要求である要求「Ｒ１１」がデキューされ、阻害要求一時格納部３６に退避される。サーバ処理部２１は、退避された要求「Ｒ１１」の実行を中断する。阻害要求管理テーブル３７は、退避された要求「Ｒ１１」を阻害要求リストに追加する。
【００３５】
図４Ａは、図３Ｂの後に、阻害要求と判定されたＣＰ１の要求「Ｒ１２」を、阻害要求として退避する旨を示す。要求「Ｒ１２」の要求元は、阻害要求管理テーブル３７の端末処理部ＩＤ「ＣＰ１」と一致する。よって、要求「Ｒ１２」は、要求「Ｒ１１」と同様に阻害要求であるので、要求「Ｒ１１」と同様に、阻害要求一時格納部３６に退避されるとともに、阻害要求管理テーブル３７の阻害要求リストに追加される。これにより、要求「Ｒ１２」は、実行する前に退避されるので、後続の要求「Ｒ２１」を待たせずに済む。
【００３６】
図４Ｂは、図４Ａの後に、阻害要求ではないＣＰ２の要求「Ｒ２１」を、実行する旨を示す。要求「Ｒ２１」の要求元の端末処理部ＩＤ「ＣＰ２」は、阻害要求管理テーブル３７には登録されていない。よって、要求「Ｒ２１」は、阻害要求ではないので、そのままサーバ処理部２１により実行される。
【００３７】
図５Ａは、図４Ｂの後に、時間経過によりＣＰ１が阻害要求から解除される旨を示す。キューエラー履歴テーブル３２のエラー発生履歴には、現在時刻から所定時間前に発生したエラーの回数が記録されている。よって、現在時刻が経過することにより、このエラーの回数が減少する。そのため、判定対象となるエラーの回数が減少することにより阻害判定閾値を下回ると、端末処理部ＩＤ「ＣＰ１」からの要求は、阻害要求から解除される。その結果、解除された端末処理部ＩＤ「ＣＰ１」は、阻害要求管理テーブル３７から削除される。
【００３８】
図５Ｂは、図５Ａの後に、かつて阻害要求として退避されていた各要求を、キュー３１に復帰する旨を示す。阻害要求管理テーブル３７の端末処理部ＩＤ「ＣＰ１」に対応づけられていた各阻害要求「Ｒ１１，Ｒ１２」は、阻害要求の解除に伴い、退避から復帰することができる。よって、復帰可能な各要求は、阻害要求管理テーブル３７の阻害要求リストからエントリが削除されるとともに、阻害要求一時格納部３６から再びキュー３１に復帰（エンキュー）する。
【００３９】
図６Ａ〜図８は、それぞれ図１、図２に示したクライアントサーバシステムの動作を示すフローチャートである。
【００４０】
図６Ａは、キュー要求制御部３３が実行する、要求のエンキュー処理を示すフローチャートである。
【００４１】
端末処理部１１から新規に発行された、エンキュー対象の要求が存在するか否かを判定する（Ｓ１０１）。エンキュー対象の要求が存在しないときには（Ｓ１０１，Ｎｏ）、処理を終了する。
【００４２】
エンキュー対象の要求が存在するときには（Ｓ１０１，Ｙｅｓ）、その要求が阻害要求に該当するか否かを判定する（Ｓ１０２）。具体的には、エンキュー対象の要求の発行元である端末処理部ＩＤと、阻害要求管理テーブル３７に登録されている端末処理部ＩＤとが、一致するときに、エンキュー対象の要求が阻害要求に該当すると判定する。阻害要求に該当しないときには（Ｓ１０２，Ｎｏ）、そのエンキュー対象の要求を、キュー３１に格納（エンキュー）する（Ｓ１０３）。
【００４３】
一方、阻害要求に該当するときには（Ｓ１０２，Ｙｅｓ）、そのエンキュー対象の要求を、退避する（Ｓ１０４）。なお、要求の退避とは、具体的には、エンキュー対象の要求を阻害要求一時格納部３６に格納するととともに、その格納した要求のエントリを阻害要求管理テーブル３７の「阻害要求リスト」に追加する処理である。これにより、阻害要求は、キュー３１に入れられたり、サーバ処理部２１に実行されたりすること無く退避されるので、後続する他の要求に悪影響を与えずに済む。
【００４４】
図６Ｂは、キュー要求制御部３３が実行する、要求のデキュー処理を示すフローチャートである。
【００４５】
まず、キュー３１の先頭に格納されているデキュー対象の要求を、キューに残したまま読み取る（Ｓ１１１）。その読み取った要求が、阻害要求に該当するか否かを判定する（Ｓ１１２）。阻害要求に該当するときには（Ｓ１１２，Ｙｅｓ）、デキュー対象の要求をキューからデキューし、Ｓ１０４と同様に退避する（Ｓ１１４）。
【００４６】
一方、阻害要求に該当しないときには（Ｓ１１２，Ｎｏ）、その読み取った要求をサーバ処理部２１に通知し、実行させる（Ｓ１１３）。そして、Ｓ１１３でのサーバ処理部２１の実行結果としてエラーが発生したか否かを判定する（Ｓ１１５）。エラーが発生しないときには（Ｓ１１５，Ｎｏ）、デキュー対象の要求をキューからデキューし、その要求の実行結果を端末処理部１１に返答する（Ｓ１１６）。エラーが発生したときには（Ｓ１１５，Ｙｅｓ）、キューエラー履歴テーブル３２の「エラー発生履歴」に、今回の実行結果を追加する（Ｓ１１７）。
【００４７】
図７は、阻害要求管理部３８が実行する、阻害要求の登録処理を示すフローチャートである。
【００４８】
まず、キューエラー履歴テーブル３２の「エラー発生履歴」のエラー回数を、現在時刻に基づいて更新する（Ｓ２０１）。つまり、更新されるエラー回数は、キューエラー履歴テーブル３２の「阻害判定閾値」で指定されている現在時刻からさかのぼった所定時間内で発生したエラー回数である。
【００４９】
次に、自装置のキューエラー履歴テーブル３２に、阻害要求に該当するレコードが存在するか否かを判定する（Ｓ２０２）。具体的には、キューエラー履歴テーブル３２の所定レコードの「エラー発生履歴」のエラー回数（Ｓ２０１で更新）が、対応する「阻害判定閾値」以上であるとき、所定レコードの「端末処理部ＩＤ」から発行された要求を阻害要求とする。阻害要求が存在しないときには（Ｓ２０２，Ｎｏ）、処理をＳ２０５に進める。
【００５０】
阻害要求が存在するときには（Ｓ２０２，Ｙｅｓ）、該当する阻害要求の「端末処理部ＩＤ」を、自装置の阻害要求管理テーブル３７に登録する（Ｓ２０３）とともに、登録した阻害要求の「端末処理部ＩＤ」を、他装置に通知して登録させる（Ｓ２０４）。さらに、他装置のＳ２０４の処理結果として、他装置から阻害要求の「端末処理部ＩＤ」を受信したときには（Ｓ２０５，Ｙｅｓ）、受信した阻害要求の「端末処理部ＩＤ」を、自装置の阻害要求管理テーブル３７に登録する（Ｓ２０６）。これにより、１つの装置内で発生した阻害要求が、複数の装置間で共有される。
【００５１】
図８は、阻害要求管理部３８が実行する、阻害要求の復帰処理を示すフローチャートである。
【００５２】
まず、Ｓ２０１と同様に、キューエラー履歴テーブル３２の「エラー発生履歴」のエラー回数を、現在時刻に基づいて更新する（Ｓ３０１）。
【００５３】
次に、自装置のキューエラー履歴テーブル３２に阻害要求から復帰するレコードが存在するか否かを判定する（Ｓ３０２）。具体的には、キューエラー履歴テーブル３２の「エラー発生履歴」のＳ３０１により更新されたエラー回数が対応する「阻害判定閾値」未満であり、かつ、既に阻害要求管理テーブル３７に登録されているレコードが、阻害要求から復帰するレコードである。復帰するレコードが存在しないときには（Ｓ３０２，Ｎｏ）、処理をＳ３０５に進める。
【００５４】
復帰するレコードが存在するときには（Ｓ３０２，Ｙｅｓ）、該当する阻害要求の認定を解除する（Ｓ３０３）とともに、解除した阻害要求の「端末処理部ＩＤ」を、他装置に通知（Ｓ３０４）して、他装置においても解除させる。さらに、他装置のＳ３０４の処理結果として、他装置から解除する阻害要求の「端末処理部ＩＤ」を受信（Ｓ３０５）したときには、受信した解除する阻害要求の「端末処理部ＩＤ」を、阻害要求管理テーブル３７から削除する（Ｓ３０６）。なお、Ｓ３０３またはＳ３０６の処理は、具体的には、阻害要求管理テーブル３７に登録されている「端末処理部ＩＤ」から復帰するレコードの「端末処理部ＩＤ」を削除することで、実現される。これにより、１つの装置内で解除した阻害要求が、複数の装置間で共有される。
【００５５】
そして、Ｓ３０３またはＳ３０６の結果、削除された「端末処理部ＩＤ」に対応する阻害要求として退避されていた要求が存在するときには（Ｓ３０７，Ｙｅｓ）、その退避されていた要求を復帰するキュー３１を特定し（Ｓ３０８）、特定したキュー３１に、退避されていた要求を復帰（エンキュー）する（Ｓ３０９）。Ｓ３０９の結果、阻害要求管理テーブル３７に登録されている「阻害要求リスト」から復帰する要求のＩＤは、削除される。
【００５６】
なお、Ｓ３０８での復帰先のキュー３１の特定方法は、例えば、以下の（１）〜（４）に示す方法のいずれかにより実現される。
（１）空いているキュー３１を復帰先として特定することで、負荷分散を行う。なお、各キュー３１の混み具合は、キュー格納量管理部３５を介して、キュー格納量管理テーブル３４から取得できる。
（２）退避される前にデキューされた、または、エンキューされようとしていたキュー３１を復帰先として特定する。
（３）１つの物理計算機内に１つ以上構築された仮想計算機として、サーバ装置２が実現されているときには、格納されている阻害要求一時格納部３６を有するサーバ装置２から見て、別の物理計算機内のキュー３１を復帰先として特定する。
（４）前記（３）の候補が複数存在するときには、その候補の中から前記（１）で示した空いているキュー３１を復帰先として特定する。
【００５７】
以上説明した本実施形態において、特許文献１に開示されたように、エンキュー処理（Ｓ１０３、Ｓ３０９）で１つの要求を複数のキューに複製することとしてもよい。これにより、負荷分散効果が得られるとともに、本実施形態の阻害要求の退避処理により、処理効率の低下を抑制できる。
【００５８】
また、本実施形態において、エラーが頻発する要求の発行元である「端末処理部ＩＤ」を、阻害要求の特定情報として使用した。しかし、阻害要求の特定情報は、「端末処理部ＩＤ」に限定されず、エラーが頻発する要求を特徴づける任意の情報を活用してもよい。例えば、特定のクライアント端末１から発行される要求にエラーが頻発するときには、阻害要求の特定情報を、要求を発行するクライアント端末１の「端末ＩＤ」とすることにより、特定のクライアント端末１からの要求を効率的に退避できる。
【００５９】
同様に、端末処理部１１が実行する特定の業務処理の要求にエラーが頻発するときには、阻害要求の特定情報を、要求に含まれる業務処理の種別を特定するＩＤとすると有効である。さらに、端末処理部１１を実行するために読み出される特定のアプリケーションプログラムにエラーが頻発するときには、そのアプリケーションプログラムのＩＤを、阻害要求の特定情報とすると有効である。
【００６０】
ところで、阻害要求一時格納部３６に退避された阻害要求について、図８ではその復帰処理を示したが、時間を経過しても阻害要求として残り続ける要求も考えられる。そこで、阻害要求管理部３８は、阻害要求管理テーブル３７を監視し、あらかじめ設定された所定期間中、ずっと阻害要求でありつづけた要求は、今後も阻害要求から復帰する見込みがないとして、中断することとしてもよい。要求の中断に伴い、各記憶部（キューエラー履歴テーブル３２、阻害要求一時格納部３６、阻害要求管理テーブル３７）からは、中断された要求に関するエントリが削除されるとともに、サーバ処理部２１には中断する阻害要求の実行を中止するよう通知し、端末処理部１１には中断した旨を返答する。これにより、阻害要求一時格納部３６が溢れることを抑制できる。
【００６１】
さらに、要求の中断は、前記したように阻害要求管理部３８が判断する他、例えば、端末処理部１１のウィンドウの「×」アイコンのクリック操作などにより発行される、端末処理部１１からの中断通知を受け付けることにより、実行してもよい。
【図面の簡単な説明】
【００６２】
【図１】本発明の一実施形態に関するクライアントサーバシステムを示す構成図である。
【図２】本発明の一実施形態に関するクライアントサーバシステムを示す機能概要図である。
【図３Ａ】本発明の一実施形態に関する要求に実行エラーが発生した旨を示す説明図である。
【図３Ｂ】本発明の一実施形態に関する実行エラーが発生した要求を阻害要求として退避する旨を示す説明図である。
【図４Ａ】本発明の一実施形態に関する阻害要求と判定された要求を退避する旨を示す説明図である。
【図４Ｂ】本発明の一実施形態に関する阻害要求ではない要求を実行する旨を示す説明図である。
【図５Ａ】本発明の一実施形態に関する時間経過により、阻害要求を解除する旨を示す説明図である。
【図５Ｂ】本発明の一実施形態に関する退避されていた各要求を復帰する旨を示す説明図である。
【図６Ａ】本発明の一実施形態に関する要求のエンキュー処理を示すフローチャートである。
【図６Ｂ】本発明の一実施形態に関する要求のデキュー処理を示すフローチャートである。
【図７】本発明の一実施形態に関する阻害要求の登録処理を示すフローチャートである。
【図８】本発明の一実施形態に関する阻害要求の復帰処理を示すフローチャートである。
【符号の説明】
【００６３】
１      クライアント端末
２      サーバ装置
３      スケジューラ
９      ネットワーク
１１    端末処理部
２１    サーバ処理部
３１    キュー
３２    キューエラー履歴テーブル
３３    キュー要求制御部
３４    キュー格納量管理テーブル
３５    キュー格納量管理部
３６    阻害要求一時格納部
３７    阻害要求管理テーブル
３８    阻害要求管理部
６１    ＣＰＵ
６２    ディスプレイ
６３    キーボード
６４    ２次記憶装置
６５    ネットワークインタフェース
６６    主記憶装置
【図１】
2009129376.tif 000006
【図２】
2009129376.tif 000007
【図３Ａ】
2009129376.tif 000008
【図３Ｂ】
2009129376.tif 000009
【図４Ａ】
2009129376.tif 000010
【図４Ｂ】
2009129376.tif 000011
【図５Ａ】
2009129376.tif 000012
【図５Ｂ】
2009129376.tif 000013
【図６Ａ】
2009129376.tif 000014
【図６Ｂ】
2009129376.tif 000015
【図７】
2009129376.tif 000016
【図８】
2009129376.tif 000017