JP6818014B2 - ジョブ用の動作リトライ方法及び機器 - Google Patents

Description

本出願は、２０１５年９月１８日出願で「OPERATION RETRY METHOD AND APPARATUS FOR JOB」なる名称の中国特許出願第２０１５１０６０１１１６．５号の優先権を主張し、その中国特許出願は、その内容全体における参照により本明細書に援用される。

技術分野
本出願は、コンピュータ処理技術の分野に関し、特にジョブ用の動作リトライ方法及びジョブ用の動作リトライ機器に関する。

背景技術
コンピュータシステムにおいて、ジョブは、進行しているときに別のシステム（サービス）とインタラクションし、ジョブは、別のシステム（サービス）において短時間の利用不能（サービス中断）が発生した場合に進行に失敗する。

ビッグデータのシナリオにおいて、実行エラーが、既存の製品において発生すると、ジョブは、一般にリトライされる。即ち、ジョブは、ジョブが引き続き進行してジョブの成功率を最大限まで保証するように、別のシステム（サービス）が回復するまで待機する。

そうではなく全てのリトライが失敗した場合に、ジョブ全体が失敗する。

例えば、別のシステム（サービス）が、１０分間ずっと利用不能な場合に、リトライ間の時間間隔は、一般に１０分を超える必要があるが、そのとき、かかる短時間の利用不能が発生した場合に、ジョブが、引き続き進行できることが保証され得る。

リトライが、全て１０分に調整される場合に、リトライコストは、間違いなく増加され、それは、次のように２つの態様に反映される。
１． 短いジョブ、例えば、３０分の間だけ進行すると予想されるジョブに関して、リトライによる実際の進行時間は、正常進行時間より長くなり得る。
２． 管理者が、ジョブを手動で停止させる必要がある場合に、特に外部システム（サービス）が利用不能な場合に、管理者は、ジョブを停止させて幾つかの調整及び配置を行うために、動作及び保守を手動で実行する必要がある。ジョブのリトライが、その時に偶然生じた場合に、ジョブは、ジョブが１０分にわたってリトライされてしまうまで、完全には停止させることができない。

従って、現在、リトライ時間選択に関して、最大リトライ時間ではなく、特定の比率を満たす平均値又は時間が、一般に選択される。

例えば、利用不能時間が、全ての外部システム（サービス）に関して１分であり、且つ最大利用不能時間が、１０分である場合に、ほとんどのリトライが成功できることを保証するために２分のリトライ時間が一般に選択される。

しかしながら、長いジョブに関して、かかる解決法は、リトライコストを増加させる可能性がある。

例えば、１０時間進行するジョブに関し、１０時間のジョブが８０％進行したとき、即ち、８時間進行したとき、最大リトライ時間を超過する１０分のサービス中断が発生すると、ジョブは失敗し、ジョブが再実行される場合に、それは、前の８時間の実行が無駄にされ、コストが巨大であることを意味する。

発明の概要
前述の問題を考慮して、本出願の実施形態は、問題を克服するか又は問題を少なくとも部分的に解決するために、ジョブ用の動作リトライ方法及びジョブ用の対応する動作リトライ機器を提供するために提案される。

前述の問題を解決するために、本出願の実施形態は、ジョブ用の動作リトライ方法であって、
ジョブにおける動作が失敗したかどうかを検出することであって、失敗したことを検出した場合にジョブの進捗に関する統計をとることと、
ジョブの進捗に従ってリトライ時間を計算することと、
リトライ時間の間待機した後で動作を再実行することと、
を含む方法を開示する。

任意選択的に、ジョブは、データ同期化ジョブであり、ジョブにおける動作が失敗したかどうかを検出するステップは、
ソース装置からのデータ読み出しが、失敗若しくはタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定すること
及び／又は
データ同期化サービスとのインタラクションが、失敗若しくはタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定すること
及び／又は
宛先装置へのデータ書き込みが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定することを含む。

任意選択的に、ジョブの進捗に従ってリトライ時間を計算するステップは、
ジョブの進捗に従って増加係数を構成することと、
事前設定の間隔に従ってリトライ時間ベースを計算することと、
増加係数及びリトライ時間ベースに従ってリトライ時間を計算することと、
を含む。

任意選択的に、事前設定の間隔に従ってリトライ時間ベースを計算するステップは、
現在のリトライ時間を取得することと、
時間ベースとして事前設定の間隔及び現在のリトライ時間の積を計算すること
又は
時間ベースとして事前設定の間隔を増加させるために、指数として現在のリトライ時間を用いることと、
を含む。

任意選択的に、ジョブの進捗に関する統計をとるステップの前に、方法は、
動作が、再実行される必要があるかどうかを判定することと、
必要があると判定した場合に、ジョブの進捗に関する統計を行うステップを実行すること又は
必要がないと判定した場合に、動作の再実行を終了することと、
を更に含む。

任意選択的に、動作が再実行される必要があるかどうかを判定するステップは、
時間条件及び／又は状態条件が、満たされているかどうかを判定することと、
満たされていると判定した場合に、動作が再実行される必要がないと決定すること又は
満たされていないと判定した場合に、動作が再実行される必要があると決定することと、
を含み、
時間条件は、現在のリトライ時間が、事前設定のリトライ時間閾値を超過することであり、
状態条件は、ジョブが停止されることである。

前述の問題を解決するために、本出願の実施形態は、ジョブ用の動作リトライ機器であって、
ジョブにおける動作が失敗したかどうかを検出し、失敗したことを検出した場合に進捗統計モジュールを呼び出すように構成されたジョブ検出モジュールと、
ジョブの進捗に関する統計をとるように構成された進捗統計モジュールと、
ジョブの進捗に従ってリトライ時間を計算するように構成されたリトライ時間計算モジュールと、
リトライ時間の間待機した後で動作を再実行するように構成されたジョブリトライモジュールと、
を含む動作リトライ機器を更に開示する。

任意選択的に、ジョブ検出モジュールは、
ソース装置からのデータ読み出しが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定するように構成された第１の決定サブモジュール
及び／又は
データ同期化サービスとのインタラクションが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定するように構成された第２の決定サブモジュール
及び／又は
宛先装置へのデータ書き込みが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定するように構成された第３の決定サブモジュールを含む。

任意選択的に、リトライ時間計算モジュールは、
ジョブの進捗に従って増加係数を構成するように構成された増加係数計算サブモジュールと、
事前設定の間隔に従ってリトライ時間ベースを計算するように構成されたリトライ時間ベース計算サブモジュールと、
増加係数及びリトライ時間ベースに従ってリトライ時間を計算するように構成された増加調整サブモジュールと、
を含む。

任意選択的に、リトライ時間ベース計算サブモジュールは、
現在のリトライ時間を取得するように構成されたリトライ時間取得ユニットと、
時間ベースとして事前設定の間隔及び現在のリトライ時間の積を計算するように構成された定数計算ユニット
又は
時間ベースとして事前設定の間隔を増加させるために、指数として現在のリトライ時間を用いるように構成された指数計算ユニットと、
を含む。

任意選択的に、ジョブ用の動作リトライ機器は、
動作が、再実行される必要があるかどうかを判定し、必要であると判定した場合に進捗統計モジュールを呼び出し、または必要でないと判定した場合にリトライ終了モジュールを呼び出すように構成されたリトライ決定モジュールと、
動作の再実行を終了するように構成されたリトライ終了モジュールと、
を更に含む。

任意選択的に、リトライ決定モジュールは、
時間条件及び／又は状態条件が満たされているかどうかを判定し、満たされていると判定した場合に第４の決定サブモジュールを呼び出し、または満たされていないと判定した場合に第５の決定サブモジュールを呼び出すように構成された条件判定サブモジュールと、
動作が、再実行される必要がないと決定するように構成された第４の決定サブモジュールと、
動作が、再実行される必要があると決定するように構成された第５の決定サブモジュールと、
を含み、
時間条件は、現在のリトライ時間が、事前設定のリトライ時間閾値を超過することであり、
状態条件は、ジョブが停止されることである。

本出願の実施形態は、以下の利点を含む。

本出願の実施形態において、ジョブにおける動作が失敗した場合に、リトライ時間が、ジョブの進捗に従って適応的に計算され、それは、特に長いジョブ用にリトライ時間の長さを大幅に増加させる。それによって、ジョブは、動的にリトライされ、それは、より長いサービス中断に対処することができ、ジョブの失敗及びジョブ再実行によって引き起こされる装置資源の浪費を回避し、且つジョブの成功率を保証しながらリトライコストを大幅に低下させる。

本出願の実施形態によるリトライポリシーにおいて、ジョブの状態が、追加的に検出され、ジョブが停止された場合に、リトライは終了され、それは、素早いリトライの終了及び退出を実現し、装置資源の浪費を更に低減し、且つリトライコストを低下させる。

本出願によるジョブ用の動作リトライ方法の実施形態１におけるステップ流れ図である。 本出願の実施形態によるオフライン同期化ツールのアーキテクチャ図である。 本出願によるジョブ用の動作リトライ方法の実施形態２におけるステップ流れ図である。 本出願によるジョブ用の動作リトライ機器の実施形態１における構造ブロック図である。 本出願によるジョブ用の動作リトライ機器の実施形態２における構造ブロック図である。

詳細な説明
本出願の目的、特徴及び利点をより明確に且つより分かりやすくするために、本出願は、添付の図面及び特定の実装形態の方法に関連して以下で更に詳細に説明される。

図１を参照すると、本出願によるジョブ用の動作リトライ方法の実施形態１におけるステップ流れ図が示され、その図は、以下のステップを特に含んでもよい。

ステップ１０１．ジョブにおける動作が失敗したかどうかが検出される。失敗したことを検出した場合に、ステップ１０２が実行される。

幾つかのオペレーティングシステムにおいて、ジョブは、コンピュータオペレータ（又はジョブスケジューラと呼ばれるプログラム）によってオぺレーティングシステムに分配される実行ユニットである。

例えば、ジョブは、毎週実行される従業員給与計算プログラムなどのアプリケーションプログラムを実行している可能性がある。

ジョブは、通常、バッチモードで進行する。

オペレータ又はジョブスケジューラは、実行されるジョブのバッチ（従業員給与計算、コスト分析、従業員ファイルアップグレード等）をオペレーティングシステムに分配する。これらのジョブは、オペレーティングシステムが、時間に敏感なインタラクション型動作を実行しない場合に、実行される。

本出願のこの実施形態において、例えば、ジョブは、データ同期化ジョブであり、データ同期化ジョブは、同期化ツールを用いることによって実行されてもよい。

図２に示されているように、同期化ツールは、複数のデータベース間の同期化を実現するための汎用ツールである。

同期化ツールは、ｄａｔａｘサービス（データ同期化サービス）を有する一連のワーカ（ワーキング装置）を含む。

ｄａｔａｘサービスは、ジョブ用のコマンド（例えば、ジョブを開始する、ジョブを停止させる等）を受信し、ワーカは、ジョブを実行するために選択され、且つｄａｔａｘサービスに状態を返す。

同期化中に、ワーキング装置は、ソース装置からデータを読み出し、宛先装置にデータを書き込む。

ソース装置及び宛先装置は、任意の関係データベース（例えば、MySQL、PostgreSQL及びHBase）又は非関係データベースである。

例えば、ワーキング装置は、MySQLからデータを読み出し、HBaseにデータを書き込んでもよい。

ジョブは、実行されているときに、ソース装置、宛先装置、及びｄａｔａｘサービスとインタラクションする。

ソース装置からのデータ読み出し（動作）中に、ソース装置によって提供されるデータ読み出しアプリケーションプログラミングインターフェース（ＡＰＩ）によって返される結果は、通常は成功、失敗又はタイムアウトである。

ソース装置からのデータ読み出しが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗だと決定されてもよい。

ｄａｔａｘサービスとのインタラクション（動作）中に、ｄａｔａｘサービスによってインタラクションされる対話ＡＰＩによって返される結果は、通常は成功、失敗又はタイムアウトである。

データ同期化サービスとのインタラクションが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗だと決定されてもよい。

宛先装置へのデータ書き込み（動作）中に、宛先装置によって提供されるデータ書き込みＡＰＩによって返される結果は、通常は成功、失敗又はタイムアウトである。

宛先装置へのデータ書き込みが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗だと決定されてもよい。

失敗及びタイムアウトの場合に、ジョブが失敗しリトライされてもよいと決定される。

確かに、上記のジョブ及びその失敗判定方法は、単に例であり、本出願のこの実施形態が実施される場合に、別のジョブ及びその失敗判定方法が、実際の状況に従って設定されてもよく、それは、本出願のこの実施形態において制限されない。なおまた、上記のジョブ及びその失敗判定方法に加えて、当業者は、実際の必要性に従って別のジョブ及びその失敗判定方法を更に用いてもよく、それは、本出願のこの実施形態において制限されない。

ステップ１０２．ジョブの進捗に関する統計がとられる。

実際の適用中に、ワーキング装置は、ジョブを実行しているときに、ジョブの進捗に関する統計をとってもよい。

例えば、統計は、バッチで取得され、その場合に完全なジョブは、複数のフラグメントに分割されてもよく、且つジョブの進捗に関する統計は、フラグメントの完了度に関する統計をとることによって取得することができる。

例えば、完全なジョブが、１０，０００のフラグメントに分割され、ジョブの進捗は、１００のフラグメントが完了されるたびに１％前に進む。

ステップ１０３．リトライ時間が、ジョブの進捗に従って計算される。

本出願のこの実施形態において、ジョブの進捗は、係数として用いられ、リトライ時間は、係数に従って計算される。リトライ時間は、ジョブの進捗に正比例し、その結果、より長いサービス中断が対処され得る。

例えば、８０％の進捗におけるリトライ時間は、３０％の進捗におけるリトライ時間より明らかに大きく、その結果、ジョブは、ジョブの再実行によって引き起こされる無駄を回避するために、サービスが回復するのを待つ十分な時間を有する。

本出願の実施形態において、ステップ１０３は、以下のサブステップを含んでもよい。

サブステップＳ１１．増加係数が、ジョブの進捗に従って構成される。

実際の適用中に、増加係数は、主としてジョブの進行状態に従って決定され、且つリトライ時間に対するジョブの進捗の影響を表すことができる。

一般に、ジョブの進捗は、増加係数に正比例する。即ち、ジョブのより大きな進捗は、より大きな増加係数を示す。反対に、ジョブのより小さな進捗は、より小さな増加係数を示す。

例えば、１５％の進捗を伴うジョブは、１．１５の増加係数を有し、８０％の進捗を伴うジョブは、１．８０の増加係数を有する。

サブステップＳ１２．リトライ時間ベースが、事前設定の間隔によって計算される。

本出願のこの実施形態において適用されているように、リトライポリシー、例えば一定時間又は指数関数的成長ベース、間隔、許容された最大リトライ時間等によるリトライが、事前に設定されてもよい。

現在のリトライ時間が取得される場合に、リトライ時間ベースは、リトライポリシーに従って計算されてもよい。

リトライポリシーが、一定時間のリトライポリシーである場合に、リトライは、間隔を置いて実行される。例えば、リトライが、３０秒の間隔で３回実行されることが指定される。

次に、事前設定の間隔及び現在のリトライ時間の積が、時間ベースとして計算されてもよい。

リトライポリシーが、指数関数的成長リトライポリシーである場合に、現在のリトライ時間は、指数として用いられてもよく、事前設定の間隔は、時間ベースとして増加される。

例において、時間ベース＝間隔＊２ｎ−１であり、ｎは、現在のリトライ時間である。

例えば、リトライが、１０ｓの間隔で４回実行されること、即ち、第１のリトライ用の時間が、１０ｓであり、第２のリトライ用の時間が、１０ｓ＊２であり、第３のリトライ用の時間が、１０ｓ＊４であり、第４のリトライ用の時間が、１０ｓ＊８であることが指定される。

サブステップＳ１３．リトライ時間は、増加係数及びリトライ時間ベースに従って計算される。

通常、増加係数及びリトライ時間ベースの積は、リトライ時間として直接計算されてもよい。

ステップ１０４．動作は、リトライ時間の間待機した後で再実行される。

本出願のこの実施形態において、ジョブは、リトライ時間の間待機した後でリトライされてもよい。

例えば、ジョブは、データ同期化ジョブである。ジョブが失敗した場合に、ソース装置からのデータ読み出しが、再実行されてもよいか、ｄａｔａｘサービスとのインタラクションが、再実行されてもよいか、又は宛先装置へのデータ書き込みが、再実行されてもよい等である。

ビッグデータシナリオにおいて、実行エラーが、既存の製品において発生した場合に、ジョブは、一般にリトライされる。即ち、ジョブは、ジョブが引き続き進行してジョブの成功率を最大限まで保証するように、別のシステム（サービス）が回復するまで待機する。

例えば、ｄａｔａｘサービスを用いるオフライン同期化中に、電子ビジネスプラットホーム上の同期量は、一日約３００Ｔであり、毎日約６０，０００の同期化ジョブがある。

これらのジョブは、たいてい相異なる時間で完了され、３０分で完了されるものもあり、２時間で完了されるものもあり、１０時間で完了されるものもあり、より長い時間で完了されるものさえある。

比較的短時間（例えば、３０分）で完了されるジョブ、即ち、短いジョブに関し、ネットワーク切断又はサービス再始動などの時折のエラーが発生し、且つリトライが終了するときにまだ除去されていない場合に、ジョブ全体を再実行するためのコストは、一般に許容可能である。

しかしながら、比較的長い時間（例えば、１０時間）で完了するジョブ、即ち、長いジョブに関し、進行中の進捗が５０％超に達したときにリトライが成功できない場合に、ジョブ全体を再実行するためのコストは比較的高い。

リトライ時間又はリトライ間隔が、リトライ用に単純に調整される場合に、全てのジョブは、同じリトライコストを有する。

例えば、リトライは、１０分に調整される。次に、全ての短いジョブは、更に実際の作業時間より長いリトライ時間を有することさえあり得、それは、不適切であり、大きなコストにつながる。

特に、ユーザが、ジョブを停止したいと思い、ジョブが、偶然リトライされる場合に、ユーザは、リトライが終了するまで待機しなければならず、次にジョブが終了され得る。

既存のリトライポリシーは、低いジョブ成功率の問題に対処できるだけであり、そこではリトライ時間又は時間間隔が調整され、一定時間又は指数関数的成長リトライポリシーにかかわらず、リトライコストの問題は、解決することができず、余分なリトライコストがもたらされる。

本出願のこの実施形態において、ジョブにおける動作が失敗した場合に、リトライ時間は、ジョブの進捗に従って適応的に計算され、それは、特に長いジョブ用のリトライ時間の長さを大幅に増加させる。それによって、ジョブは、そのために動的にリトライされ、それは、より長いサービス中断に対処し、ジョブの失敗及びジョブ再実行によって引き起こされる装置資源の浪費を回避し、且つジョブの成功率を保証しながらリトライコストを大幅に低下させることができる。

図３を参照すると、本出願によるジョブ用の動作リトライ方法の実施形態２におけるステップ流れ図が示され、それは、以下のステップを特に含んでもよい。

ステップ３０１．ジョブにおける動作が失敗したかどうかが検出される。失敗したことが検出された場合にステップ３０２が実行される。

ステップ３０２．動作が再実行される必要があるかどうかが判定される。必要があると判定された場合にステップ３０４が実行される。必要がないと判定された場合にステップ３０３が実行される。

ステップ３０３．動作の再実行が終了される。

本出願のこの実施形態に適用されるように、リトライポリシーは、事前設定されてもよく、ジョブは、リトライポリシーに一致する場合にリトライされる。そうでなければ、リトライは終了される。

本出願の実施形態において、ステップ３０２は、以下のサブステップを含んでもよい。

サブステップＳ２１．時間条件及び／又は状態条件が満たされているかどうかが判定される。満たされていると判定された場合にサブステップＳ２２が実行される。満たされていないと判定された場合にサブステップＳ２３が実行される。

サブステップＳ２２．動作が再実行される必要がないと決定される。

サブステップＳ２３．動作が再実行される必要があると決定される。

時間条件は、現在のリトライ時間が、事前設定のリトライ時間閾値を超過することである。

状態条件は、ジョブが停止されることである。

特定の実装形態において、一定時間による又は指数関数的成長ベースのリトライなどのリトライポリシー及び許容された最大リトライ時間（即ちリトライ時間閾値）等は、全て、ジョブ構成中に、即ちジョブを構成しているときに指定されてもよく、ユーザは、エラーがジョブで発生した場合にリトライを実行する方法を指定する。

従って、ジョブが、ワーキング装置に分配される場合に、ワーキング装置は、このリトライポリシーに従ってリトライを実行する。リトライが実行されるたびに、現在のリトライ時間が、許容された最大リトライ時間（即ち、リトライ時間閾値）との比較のために記録されてもよい。許容された最大リトライ時間（即ち、リトライ時間閾値）が超過される場合に、リトライは、停止される。そうでなければ、リトライは、継続される。

ジョブが、ワーキング装置上で実行されるので、ワーキング装置は、ジョブを実行しているときにジョブの実行状態、例えば、正常な実行、実行の停止、実行時間、実行の進捗等を知ることができる。

ユーザが、ジョブを手動で停止したい場合に、特に、外部システム（サービス）が利用不能であるので、ユーザが、ジョブを停止させるために動作及びメンテナンスを手動で実行し、且つ幾つかの調整及び配置を行う必要がある場合に、ワーキング装置は、ジョブ停止命令を受信した後でできるだけ早くジョブを停止させる必要がある。

ジョブが、従来のリトライポリシーに従って偶然リトライされる場合に、ジョブは、リトライ全体が完全に終了するまで成功裡に停止させることができない。

例えば、ユーザは、ジョブが１０回リトライされるように構成し、次に、ユーザは、構成エラーがどこかで発生し、ジョブが停止される必要があることを知るが、しかしジョブは、偶然リトライされる。次に、ユーザは、１０のリトライが完全に終了するまで待機する必要があり、次にジョブは、正しく停止させることができる。

本出願のこの実施形態によるリトライポリシーにおいて、ジョブの状態が追加的に検出され、ジョブが停止される場合に、リトライは終了され、それは、素早いリトライの終了及び退出を実現し、装置資源の浪費を更に低減させ、且つリトライコストを低下させる。

ステップ３０４．ジョブの進捗に関する統計がとられる。

ステップ３０５．リトライ時間が、ジョブの進捗に従って計算される。

ステップ３０６．動作は、リトライ時間の間待機した後で再実行される。

方法の実施形態が、全て、簡単な説明のために一連の行動の組み合わせとして説明されることに留意されたいが、しかし当業者は、本出願が、説明される行動の順序に限定されないことを理解されたい。何故なら、幾つかのステップが、本出願の実施形態に従って他の順序で又は同時に実行されてもよいからである。加えて、当業者はまた、明細書で説明される全ての実施形態が、好ましい実施形態であり、関連行動が、本出願に必ずしも必須ではないことを理解されたい。

図４を参照すると、本出願によるジョブ用の動作リトライ機器の実施形態１における構成ブロック図が示され、それは、以下のモジュールを特に含んでもよい。即ち、
ジョブにおける動作が失敗したかどうかを検出し、失敗したことを検出した場合に進捗統計モジュール４０２を呼び出すように構成されたジョブ検出モジュール４０１と、
ジョブの進捗に関する統計をとるように構成された進捗統計モジュール４０２と、
ジョブの進捗に従ってリトライ時間を計算するように構成されたリトライ時間計算モジュール４０３と、
リトライ時間の間待機した後で動作を再実行するように構成されたジョブリトライモジュール４０４と、
である。

本出願の実施形態において、ジョブ検出モジュール４０１は、以下のサブモジュールを含んでもよい。即ち、
ソース装置からのデータ読み出しが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定するように構成された第１の決定サブモジュール
及び／又は
データ同期化サービスとのインタラクションが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定するように構成された第２の決定サブモジュール
及び／又は
宛先装置へのデータ書き込みが、失敗又はタイムアウトした場合に、データ同期化ジョブにおける動作が失敗したと決定するように構成された第３の決定サブモジュールである。

本出願の実施形態において、リトライ時間計算モジュール４０３は、以下のサブモジュールを含んでもよい。即ち、
ジョブの進捗に従って増加係数を構成するように構成された増加係数計算サブモジュールと、
事前設定の間隔に従ってリトライ時間ベースを計算するように構成されたリトライ時間ベース計算サブモジュールと、
増加係数及びリトライ時間ベースに従ってリトライ時間を計算するように構成された増加調整サブモジュールと、
である。

本出願の実施形態において、リトライ時間ベース計算サブモジュールは、以下のユニットを含んでもよい。即ち、
現在のリトライ時間を取得するように構成されたリトライ時間取得ユニットと、
時間ベースとして事前設定の間隔及び現在のリトライ時間の積を計算するように構成された定数計算ユニット
又は
時間ベースとして事前設定の間隔を増加させるために、指数として現在のリトライ時間を用いるように構成された指数計算ユニットと、
である。

図５を参照すると、本出願によるジョブ用の動作リトライ機器の実施形態２における構成ブロック図が示され、それは、以下のモジュールを特に含んでもよい。即ち、
ジョブにおける動作が失敗したかどうかを検出し、失敗したことを検出した場合にリトライ決定モジュール５０２を呼び出すように構成されたジョブ検出モジュール５０１と、
動作が再実行される必要があるかどうかを判定し、必要があると判定した場合に進捗統計モジュール５０４を呼び出し、必要がないと判定した場合にリトライ終了モジュール５０３を呼び出すように構成されたリトライ決定モジュール５０２と、
動作の再実行を終了するように構成されたリトライ終了モジュール５０３と、
ジョブの進捗に関する統計をとるように構成された進捗統計モジュール５０４と、
ジョブの進捗に従ってリトライ時間を計算するように構成されたリトライ時間計算モジュール５０５と、
リトライ時間の間待機した後で動作を再実行するように構成されたジョブリトライモジュール５０６と、
である。

本出願の実施形態において、リトライ決定モジュール５０２は、以下のサブモジュール、即ち、
時間条件及び／又は状態条件が満たされているかどうかを判定し、満たされていると判定した場合に第４の決定サブモジュールを呼び出し、満たされていないと判定した場合に第５の決定サブモジュールを呼び出すように構成された条件判定サブモジュールと、
動作が、再実行される必要はないと決定するように構成された第４の決定サブモジュールと、
動作が、再実行される必要があると決定するように構成された第５の決定サブモジュールと、
を含み、
時間条件は、現在のリトライ時間が、事前設定のリトライ時間閾値を超過することであり、
状態条件は、ジョブが停止されることである。

装置の実施形態は、方法の実施形態に基本的に類似しており、従って簡潔に説明される。関連部分に関して、方法の実施形態における説明が参照されてもよい。

この明細書における実施形態は、全て漸進的方法で説明される。実施形態のそれぞれにおける説明は、他の実施形態との差に集中し、それぞれの実施形態間の同一又は類似部分に関して互いに参照されてもよい。

当業者は、本出願の実施形態が、方法、機器又はコンピュータプログラム製品として提供され得ることを理解されたい。従って、本出願の実施形態は、完全なハードウェア実施形態、完全なソフトウェア実施形態、又はソフトウェア及びハードウェアを組み合わせる実施形態として実施されてもよい。更に、本出願の実施形態は、コンピュータ使用可能プログラムコードを含む１つ又は複数のコンピュータ使用可能記憶媒体（限定するわけではないが、磁気ディスクメモリ、ＣＤ−ＲＯＭ、光メモリ等を含む）上に実現されるコンピュータプログラム製品であってもよい。

典型的な構成において、コンピュータ装置は、１つ又は複数のプロセッサ（ＣＰＵ）、入力／出力インターフェース、ネットワークインターフェース、及びメモリを含む。メモリは、揮発性メモリ、ランダムアクセスメモリ（ＲＡＭ）、及び／又はコンピュータ可読媒体、例えば読み出し専用メモリ（ＲＯＭ）若しくはフラッシュＲＡＭにおける不揮発性メモリ等を含んでもよい。メモリは、コンピュータ可読媒体の例である。コンピュータ可読媒体は、不揮発性及び揮発性媒体と同様に移動可能及び移動不可能媒体を含み、且つ任意の方法又は技術によって情報の記憶を実現することができる。情報は、コンピュータ可読命令、データ構造、及びプログラム又は他のデータのモジュールであってもよい。コンピュータ記憶媒体の例は、限定するわけではないが、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのＲＡＭ、ＲＯＭ、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ若しくは他のメモリ技術、コンパクトディスク読み出し専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）若しくは他の光記憶装置、カセットテープ、磁気テープ／磁気ディスク記憶装置若しくは他の磁気記憶装置、又は任意の他の非伝送媒体を含み、且つコンピューティング装置にとってアクセス可能な情報を格納するために用いることができる。そこにおける定義によれば、コンピュータ可読媒体は、変調データ信号及びキャリアなどの一時的な媒体を含まない。

本出願の実施形態は、本出願の実施形態に従って、方法、端末装置（システム）及びコンピュータプログラム製品の流れ図及び／又はブロック図に関連して説明される。コンピュータプログラム命令が、流れ図及び／又はブロック図における各プロセス及び／又はブロック、並びに流れ図及び／又はブロック図におけるプロセス及び／又はブロックの組み合わせを実施するために用いられてもよいことを理解されたい。コンピュータプログラム命令は、マシンを生成するために汎用コンピュータ、専用コンピュータ、埋め込み型プロセッサ、又は別のプログラマブルデータ処理端末装置のプロセッサに提供されてもよく、その結果、コンピュータ、又は別のプログラマブルデータ処理端末装置のプロセッサによって実行される命令は、流れ図における１つ若しくは複数のプロセス及び／又はブロック図における１つ若しくは複数のブロックにおける指定された機能を実行するための機器を生成する。

これらのコンピュータプログラム命令はまた、コンピュータ又は別のプログラマブルデータ処理端末装置に特定の方法で働くように命令できるコンピュータ可読メモリに格納されてもよく、その結果、コンピュータ可読メモリに格納された命令は、指示機器を含む製品を生成する。指示機器は、流れ図における１つ若しくは複数のプロセス及び／又はブロック図における１つ若しくは複数のブロックにおける指定された機能を実行する。

これらのコンピュータプログラム命令はまた、コンピュータ又は別のプログラマブルデータ処理端末装置にロードされてもよく、その結果、一連の動作及びステップは、コンピュータ又は別のプログラマブル端末装置上で実行され、それによって、コンピュータ実行処理を生成する。従って、コンピュータ又は別のプログラマブル端末装置において実行される命令は、流れ図における１つ若しくは複数のプロセス、及び／又はブロック図における１つ若しくは複数のブロックにおける指定された機能を実行するためのステップを提供する。

本出願の好ましい実施形態を説明したが、当業者は、ひとたび基本的で発明的な概念を学習すれば、実施形態に対する追加の変更及び修正を行うことができる。従って、添付の特許請求の範囲は、好ましい実施形態、並びに本出願の実施形態の範囲内に入る全ての変更及び修正を含むように解釈されることが意図されている。

最後に、第１及び第２などの本明細書における関係用語が、１つのエンティティ又は動作を別のエンティティ又は動作から区別するために単に用いられ、これらのエンティティ又は動作間のどんな実際の関係又は順序も必ずしも要求も意味もしないことに更に留意されたい。更に、「含む（include）」、「含む（comprise）」という用語又はそれらのどんな他の変形も、非排他的な包含をカバーするように意図され、その結果、要素リストを含むプロセス、方法、物品又は端末装置は、それらの要素を含むだけでなく、明白には列挙されていない他の要素も含むか、又はプロセス、方法、物品若しくは端末装置に固有の要素を更に含む。別段の指定がなければ、「含む（include a/an）」によって制限される要素は、要素を含むプロセス、方法、物品又は端末装置に存在する他の同じ要素を排除しない。

本出願によるジョブ用の動作リトライ方法及びジョブ用の動作リトライ機器が、上記で詳細に説明された。本出願の原理及び実装形態の方法が、本明細書において具体例を用いることによって説明されているが、実施形態の前述の説明は、本出願の方法及び方法の中心概念の理解を助けるように意図されているだけである。一方で、当業者は、本出願の概念に従って、特定の実装形態の方法及び適用範囲に対する変形を行い得る。結論として、本明細書の内容は、本出願に対する限定として解釈されるべきでない。

Claims (18)

1. ジョブ動作リトライ方法であって、
   ジョブの動作が失敗したかどうかを検出することと、
   前記動作が失敗したという検出結果に応じて、前記ジョブの進捗に関する統計をとることと、
   前記ジョブの前記進捗に従ってリトライ時間を計算することであって、前記リトライ時間は前記進捗に応じて変化することと、
   前記リトライ時間の間待機した後で前記動作を再実行することと、
   を含む方法。
2. 前記ジョブの前記動作が失敗したかどうかを検出することが、
   ソース装置からのデータ読み出しが失敗若しくはタイムアウトした場合に、データ同期化ジョブの動作が失敗したと決定すること；
   データ同期化サービスとのインタラクションが失敗若しくはタイムアウトした場合に、前記データ同期化ジョブの動作が失敗したと決定すること；
   宛先装置へのデータ書き込みが失敗又はタイムアウトした場合に、前記データ同期化ジョブの動作が失敗したと決定すること；
   の少なくとも１つを含む、請求項１に記載の方法。
3. 前記ジョブの前記進捗に従って前記リトライ時間を計算することが、
   前記ジョブの前記進捗に基づいて増加係数を構成することと、
   事前設定の間隔に基づいてリトライ時間ベースを計算することと、
   前記増加係数及び前記リトライ時間ベースに基づいて前記リトライ時間を計算することと、
   を含む、請求項１に記載の方法。
4. 事前設定の間隔に基づいて前記リトライ時間ベースを計算することが、
   現在のリトライ回数を取得することと、
   前記リトライ時間ベースとして前記事前設定の間隔及び前記現在のリトライ回数の積を計算すること
   又は
   前記リトライ時間ベースとして前記現在のリトライ回数に基づいて前記事前設定の間隔を指数関数的に増加させることと、
   を含む、請求項３に記載の方法。
5. 前記ジョブの前記進捗に関する統計をとることの前に、前記方法が、
   前記動作が再実行される必要があるかどうかを決定することと、
   前記動作が再実行される必要があるとの決定に応じて、前記ジョブの進捗に関する統計をとることと、
   前記動作が再実行される必要がないとの決定に応じて、前記動作の再実行を終了することと、
   を更に含む、請求項１〜４のいずれか一項に記載の方法。
6. 前記動作が再実行される必要があるかどうかを決定することが、
   リトライ回数条件又は状態条件が満たされているかどうかを決定することと、
   前記リトライ回数条件又は状態条件が満たされているとの決定に応じて、前記動作が、再実行される必要がないと決定することと、
   前記リトライ回数条件又は状態条件が満たされていないとの決定に応じて、前記動作が、再実行される必要があると決定することと、
   を含み、
   前記リトライ回数条件が、事前設定のリトライ回数閾値に関連付けられており、
   前記状態条件が、前記ジョブが停止されることに関連付けられている、請求項５に記載の方法。
7. ジョブ動作リトライ機器であって、
   ジョブの動作が失敗したかどうかを検出するように構成されたジョブ検出モジュールと、
   前記動作が失敗したという検出結果に応じて、前記ジョブの進捗に関する統計をとるように構成された進捗統計モジュールと、
   前記ジョブの前記進捗に従ってリトライ時間を計算するように構成されたリトライ時間計算モジュールであって、前記リトライ時間は前記進捗に応じて変化する、リトライ時間計算モジュールと、
   前記リトライ時間の間待機した後で前記動作を再実行するように構成されたジョブリトライモジュールと、
   を含む動作リトライ機器。
8. 前記ジョブ検出モジュールが、
   ソース装置からのデータ読み出しが失敗又はタイムアウトした場合に、データ同期化ジョブの動作が失敗したと決定するように構成された第１の決定サブモジュールと、
   データ同期化サービスとのインタラクションが失敗又はタイムアウトした場合に、前記データ同期化ジョブの動作が失敗したと決定するように構成された第２の決定サブモジュールと、
   宛先装置へのデータ書き込みが失敗又はタイムアウトした場合に、前記データ同期化ジョブの動作が失敗したと決定するように構成された第３の決定サブモジュールと、
   のうち少なくとも１つを含む、請求項７に記載の機器。
9. 前記リトライ時間計算モジュールが、
   前記ジョブの前記進捗に従って増加係数を構成するように構成された増加係数計算サブモジュールと、
   事前設定の間隔に従ってリトライ時間ベースを計算するように構成されたリトライ時間ベース計算サブモジュールと、
   前記増加係数及び前記リトライ時間ベースに従ってリトライ時間を計算するように構成された増加調整サブモジュールと、
   を含む、請求項７に記載の機器。
10. 前記リトライ時間ベース計算サブモジュールが、
    現在のリトライ回数を取得するように構成されたリトライ回数取得ユニットと、
    前記リトライ時間ベースとして前記事前設定の間隔及び前記現在のリトライ回数の積を計算するように構成された定数計算ユニット
    又は
    前記リトライ時間ベースとして前記現在のリトライ回数に基づいて前記事前設定の間隔を指数関数的に増加させるように構成された指数計算ユニットと、
    を含む、請求項９に記載の機器。
11. 前記動作が再実行される必要があるかどうかを決定し、前記動作が再実行される必要があるとの決定に応じて、前記進捗統計モジュールを呼び出し、前記動作が再実行される必要がないとの決定に応じて、リトライ終了モジュールを呼び出すように構成されたリトライ決定モジュールを更に含み、前記リトライ終了モジュールが、前記動作の再実行を終了するように構成される、請求項７〜１０のいずれか一項に記載の機器。
12. 前記リトライ決定モジュールが、
    リトライ回数条件又は状態条件が満たされているかどうかを決定し、前記リトライ回数条件又は状態条件が満たされているとの決定に応じて、第４の決定サブモジュールを呼び出し、前記リトライ回数条件又は状態条件が満たされていないとの決定に応じて、第５の決定サブモジュールを呼び出すように構成された条件判定サブモジュールを含み、
    前記第４の決定サブモジュールは、前記動作が再実行される必要がないと決定するように構成され、前記第５の決定サブモジュールは、前記動作が再実行される必要があると決定するように構成され、
    前記リトライ回数条件が、事前設定のリトライ回数閾値に関連付けられており、
    前記状態条件が、前記ジョブが停止されることに関連付けられている、請求項１１に記載の機器。
13. 命令の組を格納する非一時的コンピュータ可読媒体であって、前記命令の組は、コンピュータにジョブ動作リトライ方法を行わせるように、前記コンピュータの少なくとも１つのプロセッサによって実行可能であり、前記ジョブ動作リトライ方法は、
    ジョブの動作が失敗したかどうかを検出することと、
    前記動作が失敗したという検出結果に応じて、前記ジョブの進捗に関する統計をとることと、
    前記ジョブの前記進捗に従ってリトライ時間を計算することであって、前記リトライ時間は前記進捗に応じて変化することと、
    前記リトライ時間の間待機した後で前記動作を再実行することと、
    を含む、非一時的コンピュータ可読媒体。
14. 前記ジョブの前記動作が失敗したかどうかを検出することが、
    ソース装置からのデータ読み出しが失敗若しくはタイムアウトした場合に、データ同期化ジョブの動作が失敗したと決定すること；
    データ同期化サービスとのインタラクションが失敗若しくはタイムアウトした場合に、前記データ同期化ジョブの動作が失敗したと決定すること；
    宛先装置へのデータ書き込みが失敗又はタイムアウトした場合に、前記データ同期化ジョブの動作が失敗したと決定すること；
    の少なくとも１つを含む、請求項１３に記載の非一時的コンピュータ可読媒体。
15. 前記ジョブの前記進捗に従って前記リトライ時間を計算することが、
    前記ジョブの前記進捗に基づいて増加係数を構成することと、
    事前設定の間隔に基づいてリトライ時間ベースを計算することと、
    前記増加係数及び前記リトライ時間ベースに基づいて前記リトライ時間を計算することと、
    を含む、請求項１３に記載の非一時的コンピュータ可読媒体。
16. 事前設定の間隔に基づいて前記リトライ時間ベースを計算することが、
    現在のリトライ回数を取得することと、
    前記リトライ時間ベースとして前記事前設定の間隔及び前記現在のリトライ回数の積を計算すること
    又は
    前記リトライ時間ベースとして前記現在のリトライ回数に基づいて前記事前設定の間隔を指数関数的に増加させることと、
    を含む、請求項１５に記載の非一時的コンピュータ可読媒体。
17. 前記命令の組は、
    前記動作が再実行される必要があるかどうかを決定することと、
    前記動作が再実行される必要があるとの決定に応じて、前記ジョブの進捗に関する統計をとることと、
    前記動作が再実行される必要がないとの決定に応じて、前記動作の再実行を終了することと、
    を、前記ジョブの前記進捗に関する統計をとることの前に、前記コンピュータに更に行わせるように、前記コンピュータの前記少なくとも１つのプロセッサによって実行可能である、請求項１３〜１６のいずれか一項に記載の非一時的コンピュータ可読媒体。
18. 前記動作が再実行される必要があるかどうかを決定することが、
    リトライ回数条件又は状態条件が満たされているかどうかを決定することと、
    前記リトライ回数条件又は状態条件が満たされているとの決定に応じて、前記動作が、再実行される必要がないと決定することと、
    前記リトライ回数条件又は状態条件が満たされていないとの決定に応じて、前記動作が、再実行される必要があると決定することと、
    を含み、
    前記リトライ回数条件が、事前設定のリトライ回数閾値に関連付けられており、
    前記状態条件が、前記ジョブが停止されることに関連付けられている、請求項１７に記載の非一時的コンピュータ可読媒体。
    

Images