JP2007529080A - 過負荷防止を備えるアプリケーションサーバのためのシステムおよび方法 - Google Patents

Abstract

過負荷防止を備えるアプリケーションサーバのためのシステムおよび方法である。例えば、サーバまたはクラスタであるシステムは、サーバが過負荷となるときはいつでも、メッセージを生成し、および／または、更なる作業を拒絶するように設計される。既に負荷のかかったサーバにおいてさらなる負担を与えないようにするために、効率的な処理方法によってこれを実行する。この拒絶メッセージ又はアクションはカスタマイズ可能である。一つの実施形態に従えば、このシステムは、要求がプライオリティキューにおいて現れたところを決定し、そのキューのさらに下のそれらを拒絶する。その要求がどのワークロードマネージャへ配送されようとしているのかを決定することにより、それが最小処理時間によって迅速にこれを実行する。
【選択図】図１

Description

著作権の通知
この特許文書の開示の一部分は、著作権の保護を受ける内容を含んでいる。著作権所有者は、特許商標事務局の特許ファイル又は記録にあるような特許文書又は特許開示のファクシミリ複製を誰が行っても異論はないが、それ以外はあらゆる著作権を保持するものである。
優先権の主張
「過負荷防止を備えるアプリケーションサーバのためのシステムおよび方法」と題名付けられた２００４年５月２１日に、ナレシュレ バヌル（Ｎａｒｅｓｈ Ｒｅｖａｎｕｒｕ）およびアンノ ランゲン（Ａｎｎｏ Ｌａｎｇｅｎ）（代理人整理番号：ＢＥＡＳ−０１５６１ＵＳ０）によって出願された、米国仮出願第６０／５７３，３０７号が引用して本出願に組み込まれる。

「過負荷防止を備えるアプリケーションサーバのためのシステムおよび方法」と題名付けられた２００５年５月１９日に、ナレシュレ バヌル（Ｎａｒｅｓｈ Ｒｅｖａｎｕｒｕ）およびアンノ ランゲン（Ａｎｎｏ Ｌａｎｇｅｎ）（代理人整理番号：ＢＥＡＳ−０１５６１ＵＳ１）によって出願された米国特許出願第＿＿＿＿＿号が引用して本出願に組み込まれる。

本願発明
本発明は一般的にはアプリケーションサーバおよびメッセージングシステムに関連する。具体的には、過負荷防止を備えるアプリケーションサーバのためのシステムおよび方法に関連する。

典型的なアプリケーションサーバまたはウェブサーバ環境において、サーバは非常に短いタイムフレームの間に数千もの要求を受信しつつけることが考えられる。場合によっては、このサーバは過負荷となり、更なる要求を処理することができなくなることが考えられる。ユーザにとっては、これはページエラー、または機能が停止したページであるようにみえる。本当にいかなる効果も有さず、単に問題を悪化させるだけである場合、このユーザは一般的には要求によって、このサーバに打撃を与え続ける。必要なことはサーバが現在過負荷であることをユーザに通知できるメカニズムであって、それにより、さらなる要求を扱う必要がない間に、サーバが安定性を回復することを可能とする。伝統的なアプローチは、サーバ「オブジェクトノットファウンド（ｏｂｊｅｃｔ ｎｏｔ ｆｏｕｎｄ）」を生成するか、固定長のキューに要求を配置する。しかし、要求を特徴付ける、または、たとえば、他をサービスしている間、一分以上かかるそれらの要求を拒絶するという試みはなされていない。

本発明の実施形態にしたがえば、サーバまたはクラスタのようなシステムは、サーバが過負荷となるときはいつでも、メッセージを生成し、および／または、更なる作業を拒絶するように設計される。既に負荷のかかったサーバにおいてさらなる負担を与えないようにするために、効率的な処理方法によってこれを実行する。この拒絶メッセージ又はアクションはカスタマイズ可能である。しかし、柔軟にするという観点に基づくカスタマイズと、過度により多くのプロセッサ要求を追加するという観点に基づくカスタマイズとの間には境界がほとんど無い。とりわけ、拒絶は迅速に処理されなければならない。伝統的なアプローチは、ある要求に対して適合することに失敗する。例えば、支払保証要求が、単純なブラウジング要求のコストで通信されているような場合である。企業は、複数のサーバを設置することでこれを解決しようとするかもしれない。しかし、本発明は、単一のサーバを用いてさえ、最適な処理を可能とする。

一つの実施形態に従えば、このシステムは、要求がプライオリティキューにおいて現れたところを決定し、そのキューのさらに下のそれらを拒絶する。その要求（例えば、ｈｔｔｐ要求）がどのワークロードマネージャへ配送されようとしているのかを決定することにより、それが最小処理時間によって迅速にこれを実行する。このｈｔｔｐ要求は待ち行列ロジックによって解析され、宛て先サーブレットが決定される。管理者はどのサーブレットがその他のものより高く優先順位をつけられるべきかを設定することができる。この解析はしたがって、そのサーブレットに関連する特定のワークロードマネージャおよびその要求に対応するプライオリティを暗示する。この要求は、あまり厳格には見られないが、主に、どのワークロードマネージャまたはサーブレットがその要求を処理するかを決定するためにＵＲＬレベルのみで見られる。このシステムはある要求が現時点で処理されないであろうが、例えば、その他の要求が処理されるかもしれないというフィードバックをユーザまたは管理者へ与えるために使用されることもまた可能である。このメッセージは、現存する方法論を用いては不可能である理論的な限界の範囲内でカスタマイズされることもまた考えられる。

一つの実施形態にしたがえば、このシステムは、グローバルな過負荷閾値と共に、個別のワークロードマネージャのための閾値を特定するように構成される。要求は、仮想タイムスタンプが与えられ、優先順位にしたがって待ち行列を作る。閾値を超えた場合、その閾値優先順位以下の要求は拒絶される。

過負荷防止は、サーバまたはクラスタの全体の有用性において重要な役割を果たす。典型的なアプリケーションサーバまたはウェブサーバ環境において、サーバは非常に短いタイムフレームの間に数千の要求を受信し続けることが考えられる。場合によっては、このサーバは過負荷となり、更なる要求を処理することができなくなることが考えられる。ユーザにとっては、これはページエラー、または機能が停止したページであるようにみえる。本当にいかなる効果も有さず、単に問題を悪化させるだけである場合、このユーザは一般的には要求によって、このサーバに打撃を与え続ける。必要なことはサーバが現在過負荷であることをユーザに通知できるメカニズムであって、それにより、さらなる要求を扱う必要がない間に、サーバが安定性を回復することを可能とする。伝統的なアプローチは、サーバ「オブジェクトノットファウンド」を生成するか、固定長のキューに要求を配置する。しかし、要求を特徴付ける、または、たとえば、他をサービスしている間、一分以上かかるそれらの要求を拒絶するという試みはなされていない。他の実装は、過負荷状態に気が付かず、要求を受理しつ続ける。要求を受理することは低パフォーマンス、および不安定という結果を招く状態を悪化させる。望まれることは、そういった状態における第１の要求の失敗である。これは、クラスタにおいてはうまく動作する。というのは、負荷が残りのクラスタのメンバ間で分散されるためである。

本発明の一つの実施形態にしたがえば、たとえばサーバまたはクラスタのようなシステムは、サーバが過負荷になったときはいつでも、メッセージを生成し、および／または更なる作業を拒絶するように設計される。既に負荷のかかったサーバにおいてさらなる負担を与えないようにするために、効率的な処理方法によってこれを実行する。この拒絶メッセージ又はアクションはカスタマイズ可能である。しかし、柔軟にするという観点に基づくカスタマイズと、過度により多くのプロセッサ要求を追加するという観点に基づくカスタマイズとの間には境界がほとんど無い。とりわけ、拒絶は迅速に処理されなければならない。伝統的なアプローチは、ある要求に対して適合することに失敗する。例えば、支払保証要求が、単純なブラウジング要求のコストで通信されているような場合である。企業は、複数のサーバを設置することでこれを解決しようとするかもしれない。しかし、本発明は、単一のサーバを用いてさえ、最適な処理を可能とする。

一つの実施形態に従えば、このシステムは、要求がプライオリティキューにおいて現れたところを決定し、そのキューのさらに下のそれらを拒絶する。その要求（例えば、ｈｔｔｐ要求）がどのワークロードマネージャへ配送されようとしているのかを決定することにより、それが最小処理時間によって迅速にこれを実行する。このｈｔｔｐ要求は待ち行列ロジックによって解析され、宛て先サーブレットが決定される。管理者はどのサーブレットがその他のものより高く優先順位をつけられるべきかを設定することができる。この解析はしたがって、そのサーブレットに関連する特定のワークロードマネージャおよびその要求に対応するプライオリティを暗示する。この要求は、あまり厳格には見られないが、主に、どのワークロードマネージャまたはサーブレットがその要求を処理するかを決定するためにＵＲＬレベルのみで見られる。このシステムはある要求が現時点で処理されないであろうが、例えば、その他の要求が処理されるかもしれないというフィードバックをユーザまたは管理者へ与えるために使用されることもまた可能である。このメッセージは、現存する方法論を用いては不可能である理論的な限界の範囲内でカスタマイズされることもまた考えられる。

一つの実施形態にしたがえば、このシステムは、グローバルな過負荷閾値と共に、個別のワークロードマネージャのための閾値を特定するように構成される。要求は、仮想タイムスタンプが与えられ、優先順位にしたがって待ち行列に入れられる。閾値を超えた場合、その閾値優先順位以下の要求が拒絶される。
図１は、本発明の実施形態に従った過負荷防止サーバを使用するシステムを含む環境を示した図である。図１からわかるように、サーバ１００は、複数のクライアント１０２、１０４、１０６から要求を受理する。この場合、サーバ１００は複数のサーブレット１０８、１１０、１１２を含み、それぞれは、それらに関連付けられたワークロードマネージャを伴う。サーバはサーバ状態監視装置１１６、または同様の現在のサーバ負荷を決定するためのメカニズムを備える。このサーバはサーブレットへ要求を通信することに先立って要求を受理するためのプライオリティキュー１１８と、サーバ状態監視装置からの状態情報を受理し、プライオリティキューへの入力を制御するキューイングロジック１２４とを備える。動作中に、クライアントが要求１２６、１３０、１３８を行なったとき、この待ち行列ロジックは、所与の現システム状態にとって樹ル可能であると考えられるそれらの要求を待ち行列に入れることだけ行なうであろう。より高い優先順位として設定されるサーブレットは、より高い優先順位において待ち行列に入れられたそれらの要求を有する。より低い優先順位として構成されるサーブレットは、カスタマメッセージまたはアクションを伴う場合には、到来する要求が拒絶されること１３８が検出されるかもしれない。

実施例
以下の章においては、実行キュー長、トランザクションカウント、ＨＴＴＰセッションカウントを超えた場合、およびＯＯＭＥに遭遇した場合に取られるアクションを含む実施例について説明する。一つの実施形態に従えば、ＪＲｏｃｋｉｔ特有のＡＰＩが、各ＧＣ間隔後にメモリの使用を計算し、もし平均空きメモリが、設定された閾値より下回った場合には、通知を提供するために使用される。要求を受け入れることがまだ可能であるメンバへそれらを向けることで、これは過負荷状態のクラスタにおけるＲＭＩクライアントのより速い障害迂回を保証する。

用語、頭文字語、および略語の定義
過負荷 − より多くの要求を受け入れることは、サーバパフォーマンスおよび安定性の悪化を招くサーバ状態。このサーバは、例えば利用可能なメモリのようなそのリソース容量を越えてしまっている。

ＯＯＭ − ＶＭによって開かれるｊａｖａ．ｌａｎｇ．ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒ

ＦＤ − ファイル記述子（Ｆｉｌｅ ｄｅｓｃｒｉｐｔｏｒ）

ＯＯＭ防止
この特徴は、ＯＯＭエラーに遭遇した場合に、サーバが抜け出せるようにするものである。ＪＲｏｃｋｉｔ ＶＭにおける独自仕様のＡＰＩが、全ＧＣのそれぞれの後に、メモリの使用を計算し、平均空きメモリが閾値を下回った場合にイベントを生成するために使用される。

ＯＯＭ防止には二つの部分が存在する。ＯＯＭＥの出口、および平均空きメモリが閾値を下回った場合のｍｂｅａｎ通知である。このサーバが、要求の実行中に開始されたＯＯＭエラーを受け取り、そうするように構成されていた場合、直ちに抜け出す。これは、アプリケーションがＯＯＭエラーそれ自体を受け取らないという仮定に基づいている。このサーバがノードマネージャ（ＮｏｄｅＭａｎａｇｅｒ）またはＨＡソリューションによって支援される場合、この特徴は有効である。このサーバは通常のＶＭ端末から区別されたよく定義された終了コードをともなって抜け出すであろう。

ＪＲｏｃｋｉｔにおいて、その管理ＡＰＩは、各ＧＭ間隔後にメモリ使用量を計算するために使用される。平均空きメモリが設定された閾値を下回った場合、ローメモリ（Ｌｏｗ Ｍｅｍｏｒｙ）イベントが登録されたリスナ（ｌｉｓｔｅｎｅｒ）へ送信される。このサーバは過負荷であるとして取り扱われ、設定された過負荷アクションがとられる。通知メカニズムの設計はＪＲｏｃｋｉｔ特有でないが、この機能を備えるその他のＶＭ上で動作することに注意されたい。

ヒステリシスがローメモリ通知に組み込まれることができる。使用されるメモリにおいて上限があり、その上限の後、ローメモリ通知が送信される。そこには加減が存在し、その後には、ローメモリ通知が撤回される。

コンソールは過負荷防止セクションであって、以下のオプションを含むものを備えることができる。
ＯｕｔＯｆＭｅｍｏｒｙＥｒｒｏｒに遭遇した場合のサーバプロセスからの抜け出し。
空きメモリを計算するために使用される平均空きメモリ閾値およびメモリサンプルの数。

このサーバは、要求実行中に生成されたＯＯＭＥをとらえることができ、よく定義されたエラーコードとともに抜け出すことができる。アプリケーションがＯＯＭＥそれ自体を取り扱うわけではないと仮定する。このシステムは、内部サブシステムのどこでも可能なところで同様にＯＯＭＥを取り扱う。

管理者は空きメモリ閾値を全メモリの割合として設定することができる。このサーバは、この閾値の後、過負荷状態であると考えられ、設定された過負荷アクションがとられる。ローメモリ状態を決定するために使用されるパラメータが、ＳｅｒｖｅｒＭＢｅａｎ（例えば、ＬｏｗＭｅｍｏｒｙＳａｍｐｌｅＳｉｚｅ）内に、既に存在する。このシステムは、さらに一つの段階へ進み、Ｊｒｏｃｋｉｔおよび同程度のＶＭ製品上で過負荷アクションを実行する。

Ｊａｖａ（登録商標）プログラミングインターフェイス
サブシステムは標準ＭＢｅａｎ通知法を使用して、メモリ通知の登録を行なうことができる。以下に例を示す。
１．ＭｅｍｏｒｙＬｉｓｔｅｎｅｒをＪＶＭＲｕｎｔｉｍｅへ追加

２．ＭｙＭｅｍｏｒｙＦｉｌｔｅｒの実行

ｗｅｂｌｏｇｉｃ．ｍａｎａｇｅｍｅｎｔ．ｒｕｎｔｉｍｅ．ＭｅｍｏｒｙＮｏｔｉｆｉｃａｔｉｏｎは、ｇｅｔＦｒｅｅＭｅｍｏｒｙ（）およびｇｅｔＴｏｔａｌＭｅｍｏｒｙ（）という二つのメソッドを有することができる。ｇｅｔＦｒｅｅＭｅｍｏｒｙ（）は、「ＳｅｒｖｅｒＭＢｅａｎ．ＬｏｗＭｅｍｏｒｙＳａｍｐｌｅＳｉｚｅ」サンプルにおける平均空きメモリを戻す。

平均からメモリについての定期的な通知が、特定された通知フィルタを有するリスナへ送信される。もし、通知フィルタが特定されていない場合、通知は空きメモリがグルーバルで設定されたメモリ閾値を下回ったときのみ送信される。

実行キュー長保護
この特徴は、管理者が実行キューにおける未解決な要求の数を制限することを可能とする。基本的に、管理者はグローバルキュー閾値を定義し、その後、要求は抑圧されるであろう。この自己調節発送モデルもまた待機状態の要求をＯｖｅｒｌｏａｄＭａｎａｇｅｒに関連付けることを可能とする。このＯｖｅｒｌｏａｄＭａｎａｇｅｒはその要求クラスのための最大保留要求を決定する。ＯｖｅｒｌｏａｄＭａｎａｇｅｒは、グローバルキュー閾値を無効にする。

低フェアシェアを伴う非トランザクションＲＭＩ要求は過負荷状態のサーバにおいては直ちに拒絶される。これは一方通行（ｏｎｅ−ｗａｙ）、同期または非同期ＲＭＩに適用される。過負荷状態が固執して持続する場合、より高い優先順位の要求が拒絶され始めるであろう。このルールには幾つかの例外が存在する。

ＪＭＳのようなサブシステム行きである要求およびトランザクションは許容される。なぜなら、それらはそれら自身の過負荷管理を実行するためである。
管理要求は許容される。
コンソールのような内部管理のものから離れて、ｗｅｂａｐｐ要求は直ちに拒絶されるであろう。

より速いＲＭＩクライアント障害迂回
いくつかのまたはすべてのクラスタノードが過負荷となれば、クラスタラブル（ｃｌｕｓｔｅｒａｂｌｅ）なＲＭＩクライアントに特別な参照（ｒｅｆ）が与えられる。この特別な参照は、過負荷状態でなく、まだアプリケーション要求を受け入れることが可能なクラスタノードを指し示す。これは、クライアントが複数のノードへ試行し、失敗することを防止する。

この特徴は、ＲＭＩクライアントが、複製リストの中の入力それぞれを試行する必要なしに、過負荷状態のクラスタの中において迅速に正常なノードを特定することを可能とする。管理者が新規なクラスタノードを、過負荷を減らすことを助けるために開始した場合、それはクライアントを新しく開始したノードへ向けるであろう。

各サーバの利用可能情報、クラスタハートビート内で送信される。この利用可能情報はそのサーバが稼動中、過負荷、またはサスペンド状態であるか否かについて示す。あるサーバがその実行キュー閾値を超えるか、またはメモリが乏しくなった場合、そのサーバは過負荷状態であると考えられる。この利用可能情報はクライアントへ送り戻され、以下のように使用される。

クラスタにおけるすべてのサーバが正常である。クライアントへ送り返された複製リストはすべてのサーバ入力を有するであろう。このクライアントはその負荷バランシングポリシーに基づいて任意のサーバを自由に選択する。

クラスタにおける一つ以上のサーバが過負荷状態である。ピギーバック応答の一部として、このシステムは特別な参照をクライアントへ送信するであろう。この特別な参照は、過負荷状態でないサーバを指し示す。このクライアントは、その次の要求のためにこの特別な参照を試行する。なぜなら、それは成功のためのよい変更だからである。実行の後、このサーバは、もう一つの特別な参照、または次のクライアントの実行のために同じものを送り返すことができる。これは、過負荷状態が解消するまで継続するであろう。もしそれらが複数存在すれば、このサーバはこの特別な参照を循環させる。

新規なクラスタノードが過負荷状態を削減するために開始すれば、この特別な参照はこの新規に開始されたノードを指し示すであろう。この新規なノードにおいて溢れることを防止するために、少しの要求の後、この特別な参照は取り下げられることも可能である。すべてのクラスタノードが過負荷状態であれば、そのクライアントはある時間帯まで試行しないことを要求される。この待ち時間はサーバのスループット、実行キュー内の保留要求の数などによって決定される。

アクティブトランザクション限界
この特徴は管理者がサーバ内におけるアクティブトランザクションの数を制限することを可能とする。一度、最大限界に到達すると、そのサーバは新規のトランザクションにおいて参加することを拒絶するであろう。存在するトランザクションに関連付けられたＲＭＩコールは許容されるであろうことに注意されたい。新規のトランザクションを開始するために試行するＲＭＩコールだけが拒絶されるであろう。

コンソールはトランザクション限界を特定するためのオプションを有することができる。トランザクション限界を超えた場合、トランザクションサブシステムは、ｊａｖａｘ．ｔｒａｎｓａｃｔｉｏｎ．ＳｙｓｔｅｍＥｘｃｅｐｔｉｏｎを開始するであろう。

アクティブＨＴＴＰセッション限界
この特徴は、管理者がサーバにおけるアクティブＨＴＴＰセッションの数を制限することを可能とする。新規セッションの数を制限することはＯＯＭＥを防止する。

最大セッション限界に到達した場合、このシステムは新規なＨＴＴＰセッションを作成する要求を拒絶するであろう。クラスタにおいて、プラグインはこの要求をもう一つのクラスタノードへ出力先変更するであろう。非クラスタ化シナリオにおいて、サーバは要求を代替のサーバへ出力先変更することができる。

サーバにおいて許容されているプライマリＨＴＴＰセッションの最大数がコンソール内に設定され得る。このセッション限界がすべてのアプリケーションにわたってグローバルである。

このサーブレットコンテナは、最大セッション限界に到達した場合に、以下のアクションの内の一つを実行するであろう。
このサーバがクラスタ内にある場合、５０３応答が送り返され、プラグインがその要求を障害迂回するであろう。
もし、サーバがクラスタ内にないが、代替えのサーバが特定されている場合、サーブレットコンテナは、要求をその代替えのサーバへ出力先変更するであろう。
過負荷エラーページがｗｅｂａｐｐ記述子において特定された場合、そのサーバはその過負荷応答をクライアントへ送り返すために使用するであろう。
過負荷出力先変更ｕｒｌがコンソールにおいて特定された場合、それは、過負荷応答を送信するために使用されるであろう。

デッドロック検出
ＪＲｏｃｋｉｔにおいて、このシステムはスレッドデッドロックがあるか否かを決定し、望まれる場合は抜け出す。この特徴は、スレッドデッドロックを検出するための能力を有するＶＭにおいてのみ可能である。

このサーバは、スタックしているスレッドを定期的に確認するであろう。一以上のスレッドがスタックしていれば、このシステムはＪＲｏｃｋｉｔ管理ＡＰＩを使用し、スレッドがデッドロックに巻き込まれているか否かを確認することができる。これは、このサーバがＮｏｄｅＭａｎａｇｅｒまたはＶｅｒｉｔａｓのようなＨＡソリューションによって支援されている場合には有効である。ＨＡバックエンドがサーバを再開するであろう。これは自動失敗回復を提供する。このシステムが同じプロセス内でデッドロックを検出のみ行うであろうことに注意されたい。内部プロセスデッドロックは適用範囲外である。上記アクションはまた、サーバ内のすべてのスレッドがスタックし、自己調整スレッドモデルがさらにスレッドを追加することができない場合に実行される。

コンソールはスレッドデッドロックを検出することでサーバプロセスから抜け出すためのオプションを有することができる。このサーバは、そのスレッドの状態を定期的に監視し、それらのいずれかがスタックしているか否かを決定する。このスタックタイム間隔は、すでにコンソールを通して設定可能である。一以上のスレッドがスタックしている場合、ＪＲｏｃｋｉｔ管理ＡＰＩを使用することで、スタックしているスレッドがデッドロックに巻き込まれているか否かを確認する。このサーバはそれ自身を停止する前にログの中でスレッドダンプを保存するであろう。

チャンネル毎のＦＤ予約
管理者は、ネットワークチャンネル毎にファイル記述子予約を作成することができる。これは、サービス拒絶攻撃の間であっても管理者がサーバにアクセスすることを可能とするであろう。これは、管理ユーザが常に、重い負荷の場合でさえ、サーバへのアクセスを増加させることを保障するであろう。このサーバはサービス拒絶攻撃の間でさえ管理上のものである。

管理ユーザのためのネットワークチャンネル毎に予約されたＦＤの数を特定することが可能である。このサーバは、少なくともこの予約されたＦＤの数を管理ユーザに常に割り当てることを保障するであろう。

よく定義された終了コード
ある過負荷状態においてそれ自身を終了する間に、このサーバはよく定義された終了コードを使用する。この終了コードはシェルスクリプトやＨＡエージェントによって、サーバ再開が必要か否かを決定するために使用されることができる。表１に示されるこの終了コードはサーバ終了のために定義される。

過負荷のサーバ状態
「過負荷」状態は新しいサーバ状態として追加されることができる。このサーバが稼動中であるが、過負荷である場合に、この状態はＳｅｒｖｅｒＲｕｎｔｉｍｅＭＢｅａｎ．ｇｅｔＳｔａｔｅ（）およびＳｅｒｖｅｒＬｉｆｅＣｙｃｌｅＲｕｎｔｉｍｅＭＢｅａｎ．ｇｅｔＳｔａｔｅ（）によって戻される。この過負荷状態はその閾値に到達した実行キュー長、またはローメモリのいずれかによって発生し得る。このサーバ状態は過負荷状態が解消した後に稼動状態に戻るであろう。この状態遷移は以下のようである。
１．シャットダウン−＞スタンバイ−＞稼動−＞過負荷−＞稼動−＞シャットダウン
２．シャットダウン−＞スタンバイ−＞稼動−＞過負荷−＞失敗−＞シャットダウン

稼動状態において利用可能な操作はまた過負荷状態においてサポートされる。そこで、サーバは、過負荷状態からサスペンドされるか、またはシャットダウンされうる。分離した過負荷状態を有することは、過負荷状態が管理コンソールにおいておよび様々なＭＢｅａｎユーティリティを通して、顕著に表示されることを保証する。通知リスナをＳｅｒｖｅｒＬｉｆｅＣｙｃｌｅＲｕｎｔｉｍｅに追加することおよび過負荷通知を標準の状態変化通知方法の一部として取得することはサブシステムにとっても便利なことである。

本発明は、本開示の教示にしたがってプログラムされた従来の汎用のまたは専用のデジタルコンピュータまたはマイクロコンピュータを使用して都合よく実装することができる。好適なソフトウェアコーディングは、本ソフトウェア分野における当業者にとっては明確であるため、すぐに、本開示の教示に基づいて通常のプログラマーによって用意されるであろう。

いくつかの実施形態において、本発明は記憶媒体であって、その上または中に記憶された命令を含む記憶メディアであるコンピュータプログラムプロダクトを含む。この命令は、本発明の任意の処理をコンピュータに実行させるようにプログラムするために使用されうるものである。この記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、および磁気光学ディスク、ＲＯＭ，ＲＡＭ，ＥＰＲＯＭ，ＥＥＰＲＯＭ，ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ装置、磁気または光カード、ナノシステム（分子メモリＩＣを含む）、またはいかなるタイプのメディアまたは装置であって、命令および／またはデータを記憶することに適したものを含むことができるが、これらに限定されるものではない。

前述の本発明の説明は、説明と解説の目的で提供された。それは網羅的である、または本発明を開示された正確な形式に制限する意図ではない。これらの実施形態は、本発明の原理およびその実務上の適用を最もよく説明するために選択され、記述された。これにより、本発明のその他の当業者は本発明を様々な実施形態および特定の熟考された使用に適した様々な修正と共に理解することを可能となる。特に、様々な実施形態がＪＲｏｃｋｉｔとともに使用、または動作するように記述されている一方、他のＶＭプロダクトが使用されうることが明白である。本発明の範囲は特許請求の範囲によって定義され、およびそれらの均等物であることが意図されている。

図１は本発明の一つの実施形態に従ったサーバ負荷防止を用いるシステムを含んだ環境を示す図である。

Claims (21)

1. 過負荷防止を備えるアプリケーションサーバを提供するためのシステムであって、
   サーバであって、クライアントからの要求を受信し、そこで動作する複数のワークロードマネージャを有するサーバと、
   待ち行列ロジックであって、受信された要求の優先順位を、前記要求が向けられるワークロードマネージャの優先順位による決定に基づいて決定する待ち行列ロジックと、を備え、
   前記待ち行列ロジックは前記サーバ状態が見込み過負荷状態を示しているときは、前記要求のうちのいくらかを拒絶することを特徴とするシステム。
2. 各ワークロードマネージャがサーブレットに関連付けられ、要求が前記サーバ上で動作するサーブレットへ向けられ、前記ワークロードマネージャによって到達されることを特徴とする請求項１に記載のシステム。
3. 前記ワークロードマネージャが、それらの使用のために利用可能なスレッドタイムの一部を配置することにより、優先順位付けされることを特徴とする請求項１に記載のシステム。
4. 前記利用可能なスレッドタイムの一部が、もう一方と比較される一つのワークロードマネージャのために許容されるスレッドタイムの相対的シェア値として特定されることを特徴とする請求項３に記載のシステム。
5. 前記ワークロードマネージャがシステム管理者によって手動で優先順位付けすることが可能であることを特徴とする請求項１に記載のシステム。
6. 前記システムが前記ワークロードマネージャを優先順位付けする際に、前記システム管理者によって使用されるためのコンソールアプリケーションを備えることを特徴とする請求項５に記載のシステム。
7. 宛て先ワークロードマネージャに従って前記優先順位付けされた要求がそれらの優先順位に従ってキュー内に配置されることを特徴とする請求項１に記載のシステム。
8. 前記キュー内に配置されていない要求が拒絶されることを特徴とする請求項７に記載のシステム。
9. クライアントへ送り返されるカスタムメッセージを伴って、前記要求が拒絶されうることを特徴とする請求項１に記載のシステム。
10. このシステムは、見込み過負荷状態であることを決定するために使用するサーバの現状態についての状態情報を受信することを特徴とする請求項１に記載のシステム。
11. 過負荷防止を備えるアプリケーションサーバを提供するための方法であって、
    前記方法は、
    サーバにおいてクライアントから要求を受信する段階であって、前記サーバはその上で動作する複数のワークロードマネージャを有する、要求受信段階と、
    受信された要求の優先順位を、前記要求が向けられるワークロードマネージャの優先順位による決定に基づいて決定する優先順位決定段階と、
    前記サーバ状態が見込み過負荷状態を示すとき、前記要求の内いくらかを拒絶する拒絶段階と、を備えることを特徴とする方法。
12. 各ワークロードマネージャはサーブレットに関連付けられ、前記要求は前記サーバ上で動作するサーブレットに向けられ、前記ワークロードマネージャによって到達されることを特徴とする請求項１１に記載の方法。
13. ワークロードマネージャがそれらの使用のための利用可能なスレッドタイムの一部を割り当てることにより優先順位付けされる請求項１１に記載の方法。
14. 利用可能なスレッドタイムの前記一部が、もう一つと比較する一つのワークロードマネージャのための許容されるスレッドタイムの相対的シェア値として特定されることを特徴とする請求項１３に記載の方法。
15. 前記ワークロードマネージャはシステム管理者によって手動で優先順位付けされることが可能であることを特徴とする請求項１１に記載の方法。
16. 前記システムが前記ワークロードマネージャを優先順位付けする際に前記システム管理者によって使用されるためのコンソールアプリケーションを備えることを特徴とする請求項１５に記載の方法。
17. 宛て先ワークロードマネージャに従って優先順位付けされた前記要求がそれらの優先順位に従ってキュー内に配置されることを特徴とする請求項１１に記載の方法。
18. 前記キューに配置されていない要求は拒絶されることを特徴とする請求項１７に記載の方法。
19. クライアントへ送り返されえるカスタムメッセージを伴うメッセージが拒絶され得ることを特徴とする請求項１１に記載の方法。
20. 前記システムが、見込み過負荷状態を決定するために使用する前記サーバの現状態についての状態情報を受信することを特徴とする請求項１１に記載の方法。
21. コンピュータ読取可能媒体であって、そこに記憶された命令を含み、実行されたときにコンピュータに、
    サーバで、クライアントからの要求を受信し、前記サーバはそこで動作する複数のワークロードマネージャを有する、受信段階と、
    受信された要求の優先順位を、前記要求が向けられるワークロードマネージャの優先順位による決定に基づいて決定する決定段階と、
    前記サーバ状態が可能な過負荷状態を示しているとき前記要求の確信のあるものを拒絶する拒絶段階と、を実行させることを特徴とするコンピュータ読取可能媒体。

Images