JP2014052939A - アプリケーション実行装置、方法及びプログラム - Google Patents

Abstract

【課題】従来技術では、アプリケーションサーバでタイムアウト時間経過後も処理を継続する方法を提供していなかったため、ユーザはタイムアウトエラーを受け取り、アプリケーションの処理を再実行しなければならなかった。
【解決手段】リクエストを受けると、実行時間収集部によって実行時間が計測され、それが保持部に蓄積される。実行時間は保持部から実行時間履歴を統計処理した結果である実行見込時間と、ユーザがあらかじめ設定したタイムアウト時間及び猶予時間に基づき、タイムアウトエラーを判断する。タイムアウト時間を越えたとき、実行制御部は実行見込時間が猶予時間以内であるときは猶予時間をもってタイムアウト判断をしてアプリケーションの処理を継続させ、処理完了後に正常応答を返すことが可能となる。
【選択図】 図１

Description

本発明は、アプリケーションサーバの実行時におけるタイムアウト判断に関する。

アプリケーションはあるリクエストを受け付けるプログラムである。アプリケーションサーバは１ないし複数のアプリケーションを実行してリクエストを処理させることができるものである。アプリケーションサーバは、クライアント端末からの求めに応じてアプリケーションにリクエストを処理させる。アプリケーションの処理が定められたタイムアウト時間を越えても完了しなかった場合、従来のアプリケーションサーバはそのアプリケーションの処理を打ち切り、クライアント端末にエラーを返却していた。タイムアウト時間経過後、残りわずかな時間で処理が完了することが見込まれる場合、クライアント端末を操作しているユーザは、タイムアウトエラーを受け取るより、処理の継続による正常応答を望むケースがある。

一方で、タイムアウト時間を自動的に変更する方法などが知られている。特許文献１には、クライアント装置から受信したリクエストの処理結果をアプリケーションサーバ処理プログラムがタイムアウト管理サーバ処理プログラムに通知し、その情報に基づいてＷｅｂサーバ処理プログラムがタイムアウト値を動的に延長する方法が開示されている。

特開２０１１−０９５８６９ 特開２０１０−２２５０４４

特許文献１記載のリクエスト情報処理方法では、アプリケーションサーバはタイムアウト時間経過後も処理を継続する方法を提供していなかった。そのため、ユーザはタイムアウトエラーを受け取ったときは、リクエストをアプリケーションに再実行させる必要があったという問題点がある。

前述した問題を解決するために、本発明のアプリケーション実行装置は、アプリケーションの実行時間を計測する実行時間収集部と、アプリケーション毎のタイムアウト時間、猶予時間および実行見込時間を保持する保持手段と、実行見込時間がタイムアウト時間より長く、猶予時間内にある場合、タイムアウト時間の判断を前記猶予時間を用いて行い、それ以外の場合は前記タイムアウト時間を用いて判断する実行判断手段と、を備える。

本発明によれば、本発明のアプリケーションサーバ上で稼動しているアプリケーションの処理が、タイムアウト時間を越えても完了しなかったとき、残りわずかな時間で処理が完了するときはアプリケーションをタイムアウトエラーとせずに継続することができる。

（第１の実施形態）
本発明の第１の実施形態の構成を、図１を用いて説明する。

本実施形態におけるアプリケーション実行装置１０は、実行時間収集部１０１と、保持部１０２と、実行制御部１０３とを有する。

クライアント端末２０は、実行制御部１０３へネットワーク１を介してリクエストを送信し、実行制御部１０３が送信した処理結果を受信する。クライアント端末２０はユーザが操作することができるようディスプレイやキーボードなどの入出力機能を備える。

実行時間収集部１０１は、アプリケーションそれぞれの実行時間を収集し、それをそのアプリケーションの実行時間履歴として保持部１０２に格納させる。実行時間とは、リクエストを受付けてから、結果を返却するまでの時間のことをいう。アプリケーションが結果を返却する前にタイムアウトとなり実行を停止させられた場合は、実行時間は収集されないか、もしくはリクエスト受付から停止までの時間を実行時間とするか、のいずれを採用してもかまわない。

保持部１０２は、アプリケーションごとにタイムアウト時間と、猶予時間と、実行時間履歴と、実行見込時間とのそれぞれを保持する。またそれらの情報を要求に応じて提供する。本実施形態において、タイムアウト時間と猶予時間は、ユーザが手動で、例えば何秒などの数値を用いて設定する。設定を入力する画面やコマンドは備えられているものとする。図２に具体例を示す。
実行見込時間は、実行時間収集部１０１が収集するアプリケーションそれぞれの実行時間履歴を統計処理をして得られる時間である。例えば実行時間履歴の直近N回の平均値を採用することが出来るがこれに限られない。図３に直近3回の平均値を実行見込時間とするときの具体例を示す。

実行制御部１０３は次の機能を有する。

第一に、クライアント端末から任意のアプリケーションへのリクエストを待ち合わせる。

第二に、クライアント端末２０からネットワーク１を介して受けたリクエストに応じた処理をアプリケーションに実行させ、アプリケーションから処理結果を受け取りそれをクライアント端末２０へ送信する。

第三に、タイムアウト判断及びアプリケーションの処理停止をする。任意のアプリケーションについて、リクエストを受けてからタイムアウト時間が経過したときは、実行見込時間が猶予時間以内のときはタイムアウト判断を猶予時間によって行い、実行見込時間が猶予時間を越えているときはタイムアウト時間によってタイムアウト判断を行う。すなわち、残りわずかな時間で完了すると実行制御部１０３が判断した場合はタイムアウト時間が延長され、処理が継続する。こうすることでタイムアウトエラーをクライアント端末に返却せず、処理完了後に正常応答を返すことが可能となる。アプリケーションの停止はその処理単位への停止命令をすることによって実現するようにしてもかまわない。なお停止命令は、強制終了のみならず、処理途中のデータの破棄やロールバックなどを行ってから正常終了させるようにしてもかまわない。

次に図４のフローチャートを用いて本実施形態のアプリケーション実行装置１０の動作を説明する。

クライアント端末２０は実行制御部１０３に対してアプリケーションへのリクエストを送信する（ステップA1）。

実行制御部１０３はクライアント端末からのリクエストに応じてアプリケーションに処理を実行させる（ステップA2）。

実行時間収集部１０１は実行された当該アプリケーションの実行時間の計測開始する（ステップA3）。

実行制御部１０３は、当該アプリケーションが完了したか否かを確認する（ステップA5）。

当該アプリケーションが完了している場合には（ステップA5がYESの場合）、実行時間収集部１０１はアプリケーションの実行時間の収集を完了し、実行時間を保持部１０２に保持させる（ステップA6）。

さらに実行制御部１０３はクライアント端末２０に正常応答を返却する（ステップA7）。

当該アプリケーションが完了していない場合には（ステップA5がNOの場合）、実行制御部１０３は、当該アプリケーションについて保持部１０２に格納されたタイムアウト時間が経過したか否かを判断する（ステップA8）。

タイムアウト時間が経過していない場合には（ステップA8がNOの場合）、ステップA5に戻る。

タイムアウト時間が経過した場合には（ステップA8がYESの場合）、保持部１０２が保持する当該アプリケーションの猶予時間と、当該アプリケーションの実行見込時間とを比較する（ステップA9）。

猶予時間のほうが大きい場合は、ステップA8で用いたタイムアウト時間がすでに経過していても、当該アプリケーションをすぐにタイムアウトとせずに、猶予時間をタイムアウト時間としてタイムアウト判断をする（ステップA10、11）。

アプリケーションの実行見込時間のほうが大きい場合は、本来のタイムアウト時間によって、すぐにタイムアウトと判断をする（ステップA12）。

さらに実行制御部１０３はクライアント端末２０に異常応答（エラー）を返却する（ステップA13）。

（第１の実施形態による効果）
第一の効果は、タイムアウト時間経過後、残りわずかな時間でアプリケーションの処理が完了する見込である場合、タイムアウトとはせずに該当の処理を継続するため、クライアント端末を操作しているユーザは待ち時間を少し延ばすだけで正常応答を受け取ることができることである。

第二の効果は、タイムアウトエラーの発生率を減らすことにより、アプリケーションの処理が再実行される回数が減り、アプリケーションサーバに余計な負荷がかからなくなることである。

（第２の実施形態）
本発明の第２の実施形態の構成を、図５を用いて説明する。

本実施形態におけるアプリケーション実行装置１０はさらに、構成保持部１０４とバイトコードトランスレーション部１０５を有する。

実行時間収集部１０１は、第１の実施形態と異なり、メソッド単位の実行時間が収集対象である。実行時間収集部１０１は後述するバイトコードトランスレーション部１０５により組み込まれたインタセプタにメソッド単位の実行時間を計測させ、その結果を保持部１０２に保持させる。メソッド単位の実行時間とは、アプリケーションがメソッドを呼び出してから、メソッドが結果を返却するまでの時間である。
なおメソッドはライブラリ化され、複数のアプリケーションが利用するような形態であってもよい。
アプリケーションが結果を返却する前にタイムアウトとなりアプリケーションが実行を停止させられた場合は、そのときまでに結果を返却したメソッドについては実行時間が収集されるが、タイムアウトの後に実行される予定であったメソッドの実行時間が収集されない。またタイムアウトのときに実行中であったメソッドについては、実行時間履歴が残らないか、もしくはメソッドが呼び出されてからタイムアウトのときまでとする。

保持部１０２は、アプリケーションごとにタイムアウト時間と、猶予時間と、実行時間履歴と、実行見込時間とのそれぞれを保持する。タイムアウト時間および猶予時間は第１の実施形態と同様である。実行見込時間は、アプリケーションを構成するメソッドの実行見込時間に基づく実行見込時間である。
例えばアプリケーションがメソッドAを１回呼び出し、メソッドBを２回呼び出すように構成されている。メソッドAおよびBの実行見込時間は、それぞれのメソッドの実行時間履歴を統計処理して得られる時間であり、例えば直近N回の実行時間履歴の平均値などを用いても良い。その結果メソッドそれぞれの実行見込時間は１秒と２秒であるとする。そうするとアプリケーションの実行見込時間は、それぞれを乗じて得られる５秒となる。Nを3とした場合の具体例を図６に示す。
保持部１０２は、アプリケーションの区別なくメソッド単位の実行時間履歴を管理してもよい。そのときは複数のアプリケーションがひとつのメソッドを呼び出している場合には、当該メソッドの実行時間は、当該複数のアプリケーションの実行見込時間の基礎として用いられる。実行見込時間の算出がメソッド単位の実行時間履歴に基づくことにより、実行見込時間の算出精度の向上が期待できる。なぜならば当該履歴には全てのアプリケーションによるメソッドの実行時間が格納されているため、当該アプリケーションでタイムアウトが連続して起こり正常なアプリケーション単位の実行時間履歴が蓄積できない状況であっても、他のアプリケーションが呼び出したメソッドの実行時間履歴に基づいて実行見込時間を算出可能であるからである。

構成保持部１０４は、アプリケーションそれぞれの構成情報である、アプリケーションが呼び出すメソッドのリストとその呼び出し回数の情報を保持する。本実施形態においては、構成情報は手動で入力するようにしてもよい。あるいはランタイムでアプリケーションが構成保持部１０４に何々アプリケーションは何々メソッドを呼び出した旨を報告し、それを構成保持部１０４が自動的に蓄積するのでもかまわない。手動で入力する場合は、例えばエンジニアがプログラムを読解し、そのプログラムが呼び出すメソッドを挙げ、それを入力してもよい。あるいは自動で蓄積する場合は、アプリケーションが処理を開始する前にメソッドのエントリポイントでログ出力をさせるような一時的または恒久的なプログラム改変をして、ログに出力される実際に実行されたメソッドの順序、回数などを収集してもかまわない。構成保持部１０４は構成情報を例えばリストや表で保持し、外部の要求に応じ情報を提供する。具体例を図７に示す。

バイトコードトランスレーション部１０５は、定義されたアスペクトに基づきバイトコードトランスレーションを求めに応じて実行する。バイトコードトランスレーションとは、ソフトウェア部品を改変し、例えば任意の箇所において別のソフトウェア部品を呼び出すような指令をソフトウェア部品に対して後から追加するようなことを実現する技術である。
さらにアスペクトとは、ソフトウェア部品群に対して実行命令列の任意条件を満たす箇所において別のソフトウェア部品であるインタセプタが呼び出されることを定義するプログラム改変ルールである。インタセプタは任意のプログラムである。本実施形態におけるインタセプタは、メソッドの実行時間の計測及び実行時間収集部１０１への報告をする機能を有する。アスペクト処理系は定義されたアスペクトに基づき一括してインタセプタをアプリケーション全体にわたるソフトウェア部品に組み込むことができる。
アスペクトとは例えば「ある名前空間を対象に、任意の文字列をメソッド名に含むすべてのｐｕｂｌｉｃメソッドの実行の開始においてインタセプタＡを呼び出し、終了においてインタセプタＢを呼び出す」といったものである。アスペクトの処理系はこれを解釈し個々のメソッドについて条件を満たすものを特定し、それぞれについてバイトコードトランスレーションを実施することで、上記アスペクトが対象アプリケーションにおいて組み込まれ、実際に実行されるようにしている。なお一度組み込んだアスペクトを外したり、変更したりすることも自由である。
本実施例において、アプリケーションを構成するメソッドの開始および終了に応じたアスペクトを適用し、アスペクトに基づいてインタセプタを組み込むことにより、メソッドの実行時間を測定することが出来る。
なおバイトコードトランスレーション技術は例えばＪａｖａｓｓｉｓｔ（ｈｔｔｐ：／／ｗｗｗ．ｊａｖａｓｓｉｓｔ．ｏｒｇ）などが利用可能である。またアスペクトによるアプリケーションに対する一括のバイトコードトランスレーションはＡｓｐｅｃｔ−Ｊ（ｈｔｔｐ：／／ｗｗｗ．ｅｃｌｉｐｓｅ．ｏｒｇ／ａｓｐｅｃｔｊ／）などで利用可能である。

次にアプリケーション実行装置１０の動作について、図８のフローチャートを用いて説明する。

バイトコードトランスレーション部１０５がアプリケーションにアスペクトに基づきインタセプタを組み込む（ステップB1）。

クライアント端末２０は実行制御部１０３に対してアプリケーションの実行リクエストを送信する（ステップB2）。

実行制御部１０３はクライアント端末の実行リクエストに応じてアプリケーションに処理を実行させる（ステップB3）。アプリケーションの実行に伴い、インタセプタがメソッド単位の実行時間の測定を開始する。

実行時間収集部１０１は、前述の測定結果の取得を開始する（ステップB4）。

実行制御部１０３は、当該アプリケーションの処理が完了したか否かを確認する（ステップB5）。

当該アプリケーションが完了している場合には（ステップB5がYESの場合）、実行時間収集部１０１はアプリケーションの実行時間の計測を完了し、結果を保持部１０２に保持させる（ステップB6）。

さらに実行制御部１０３はクライアント端末２０に正常応答を返却する（ステップB7）。

当該アプリケーションの処理が完了していない場合には（ステップB5がNOの場合）、実行制御部１０３は、当該アプリケーションについて保持部１０２に格納されたタイムアウト時間が経過したか否かを判断する（ステップB8）。

タイムアウト時間が経過していない場合には（ステップB8がNOの場合）、ステップA5に戻る。

タイムアウト時間が経過した場合には（ステップB8がYESの場合）、保持部１０２が保持する当該アプリケーションの猶予時間と、当該アプリケーションの実行見込時間とを比較する（ステップB9）。当該アプリケーションの実行見込時間は、アプリケーションを構成するメソッドの実行見込時間とアプリケーションの構成情報に基づく。

猶予時間のほうが大きい場合は、ステップB8で用いたタイムアウト時間がすでに経過していても、当該アプリケーションをすぐにタイムアウトとせずに、猶予時間をタイムアウト時間としてタイムアウト判断をする（ステップB10、11）。

アプリケーションの実行見込時間のほうが大きい場合は、本来のタイムアウト時間によって、すぐにタイムアウトと判断をする（ステップB12）。

さらに実行制御部１０３はクライアント端末２０に異常応答を返却する（ステップB13）。

（第２の実施形態による効果）
第１の実施形態による効果に加え、メソッド単位での実行時間履歴に基づいて実行見込時間を算出しているため、他のアプリケーションが呼び出したメソッドの実行時間履歴も活用でき、実行見込時間の算出の精度が向上する。

（第３の実施形態）
本発明の第３の実施形態の構成を、図９を用いて説明する。本実施形態のアプリケーション実行装置１０は、第１の実施形態におけるバイトコードトランスレーション部１０５にかわりスタックトレース採取部１０６を有する。

実行中のロジックとそのロジックが実行された経過時間をデータとして保持する手段として、アプリケーションのスタックトレースを採取する方法が考えられる。スタックトレースを定期的に採取することにより、実行中のメソッドと実行時間のデータを採取可能である。

スタックトレース採取部１０６は、第一にスタックトレースの情報を採取する。Java（登録商標）のソフトウェア部品を実行するJava(登録商標)VMの多くは、実行中のプログラムがメソッドの実行をスタックフレームに保存している。スタックトレースの情報を採取するとは、すなわちスタックフレームの記録の写しを得ることである。第二に、採取したスタックトレースがその時点においてCPUにより実行されているメソッドであるスタックの最上位のメソッドが変更されたと認識した場合は、そのメソッドが終了し最上位からPopされるまでの時間を、そのメソッドの実行時間として認識する。

（第３の実施形態による効果）
第１および第２の実施形態における効果に加え、特別なバイトコードトランスレーションや、インタセプタ等を用いる必要が無い点で、システムへの影響が少ない。

第１の実施形態における構成の概略図である。 第１の実施形態における保持部の有するタイムアウト時間と猶予時間を例示した図である。 第１の実施形態における保持部の有する実行時間履歴を例示した図である。 第１の実施形態における処理の流れを示した図である。 第２の実施形態における構成の概略図である。 第２の実施形態における保持部の有する実行時間履歴を例示した図である。 第２の実施形態における保持部の有する構成情報を例示した図である。 第２の実施形態における処理の流れを示した図である。 第３の実施形態における構成の概略図である。

Claims (10)

1. アプリケーションの実行時間を計測する実行時間収集部と、
   前記アプリケーション毎のタイムアウト時間、猶予時間および実行見込時間を保持する保持手段と、
   前記実行見込時間が前記タイムアウト時間より長く、前記猶予時間内にある場合、タイムアウトの判断を前記猶予時間を用いて行い、それ以外の場合は前記タイムアウト時間を用いて判断する実行判断手段とを有するアプリケーション実行装置。
2. 前記保持手段はさらに前記アプリケーションを構成するメソッドの情報と、前記メソッドそれぞれの実行履歴とを保持し、
   前記実行見込時間は前記実行履歴の統計処理に基づいて算出される、
   請求項１記載のアプリケーション実行装置。
3. 前記メソッドはロード時に一時的に改変されることができるソフトウェア部品から構成され、
   前記メソッドの実行が開始または終了するときに呼び出されて前記メソッドの前記実行時間を計測し前記保持手段に格納させるインタセプタを前記ソフトウェア部品に付加をするソフトウェア部品処理手段
   をさらに備える請求項２記載のアプリケーション実行装置。
4. 前記アプリケーションはスタックトレースが採取可能なシステムで実行され、
   一定時間間隔で前記スタックトレースを採取して前記メソッドの実行時間を計測して保持手段格納させるスタックトレース採取部
   をさらに有する、請求項２記載のアプリケーション実行装置。
5. 実行時間収集部はアプリケーションの実行時間を計測し、
   保持手段は前記アプリケーション毎のタイムアウト時間、猶予時間および実行見込時間を保持し、
   実行判断手段は前記実行見込時間が前記タイムアウト時間より長く、前記猶予時間内にある場合、タイムアウト時間の判断を前記猶予時間を用いて行い、それ以外の場合は前記タイムアウト時間を用いて判断する、
   アプリケーション実行方法。
6. 前記保持手段はさらに前記アプリケーションを構成するメソッドの情報と、前記メソッドそれぞれの実行履歴とを保持し、
   前記実行見込時間は前記実行履歴の統計処理に基づいて算出される、
   請求項５記載のアプリケーション実行方法。
7. ソフトウェア部品処理手段は前記メソッドの実行が開始または終了するときに呼び出されて前記メソッドの前記実行時間を計測し前記保持手段に格納させるインタセプタを前記ソフトウェア部品に付加をする、
   請求項６記載のアプリケーション実行方法。
8. コンピュータに、
   アプリケーションの実行時間を計測させ、
   前記アプリケーション毎のタイムアウト時間、猶予時間および実行見込時間を保持させ、
   前記実行見込時間が前記タイムアウト時間より長く、前記猶予時間内にある場合、タイムアウト時間の判断を前記猶予時間を用いて行い、それ以外の場合は前記タイムアウト時間を用いて判断させる、
   アプリケーション実行プログラム。
9. コンピュータに、
   さらに前記アプリケーションを構成するメソッドの情報と、前記メソッドそれぞれの実行履歴とを保持させ、
   前記実行見込時間は前記実行履歴の統計処理に基づいて算出される、
   請求項８記載のアプリケーション実行プログラム。
10. コンピュータに、
    前記メソッドの実行が開始または終了するときに呼び出されて前記メソッドの前記実行時間を計測し前記保持手段に格納させるインタセプタを前記ソフトウェア部品に付加をさせる、
    請求項９記載のアプリケーション実行プログラム。

Images