プールがその並行実行数の上限に達すると、そのプールに割り当てられる新しいアテンプトはキューに格納されるか拒否されます。キューイングの動作はアテンプトの作成方法によって異なります。
| アテンプトのソース | キューイング | 補足 |
|---|---|---|
| ワークフロースケジュール | 有効 | スケジュールで起動されたアテンプトは、プールが満杯のときキューに格納されます。 |
require> オペレーター | 有効 | require> で作成されたアテンプトは、プールが満杯のときキューに格納されます。 |
| バックフィル | 有効 | バックフィルで作成されたアテンプトは、プールが満杯のときキューに格納されます。 |
PUT /api/attempts Treasure Workflow API | 条件付き | リクエストに allowQueueing=true が含まれている場合のみキューに格納されます。それ以外の場合、プールが満杯になった時点でアテンプトの作成に失敗します。Data Workbench は allowQueueing=true を送信するため、Data Workbench から作成されたアテンプトはプールが満杯のときキューに格納されます。 |
| ワークフロートリガー | 有効 | トリガーで起動されたアテンプトは、プールが満杯のときキューに格納されます。 |
allowQueueing=false への依存は避けてください
キューイングは他のすべてのアテンプトのソースにおけるデフォルトの動作です。将来のリリースでは API で起動されたアテンプトも無条件にキューに格納されるようになる予定で、その時点で allowQueueing=false は受け付けられなくなります。現在の allowQueueing=false によるフェイルファストの動作に依存したワークフローを構築しないでください。
各プールには、実行待ちのアテンプト数に対する個別の上限があります。待機アテンプト上限は、ブロック中であるかキュー待ちであるかにかかわらず、プール内でまだ実行を開始していないすべてのアテンプトを対象とします。プールが待機アテンプト上限に達すると、そのアテンプトのソースでキューイングが有効であっても、そのプールに割り当てられる新しいアテンプトの作成は失敗します。待機アテンプト上限は、同時に実行できるアテンプト数を制限する並行実行数の上限とは別の制限です。
アカウントではなくプールごと
待機アテンプト上限はプールごとに個別に適用されます。あるプールで上限に達しても、別のプールではアテンプトの作成は妨げられません。
待機アテンプト上限の現在の値については Treasure Workflow の前提条件と制限事項を参照してください。
プールが満杯で、かつ、アテンプトのソースに対してキューイングが有効でないか、プールが待機アテンプト上限に達している場合、アテンプトの作成リクエストは失敗します。ソースごとに以下のようにリカバリーされます。
- スケジュール: スケジューラーは、アテンプトが作成されるか、スケジュールの
skip_delayed_by条件が満たされてアテンプトがスキップされるまで、自動的にアテンプトの作成を再試行し続けます。 require>オペレーター: 親アテンプトが、アテンプトの作成が成功するまで自動的に再試行を続けます。- ワークフロートリガー: トリガーが、アテンプトの作成が成功するまで自動的に再試行を続けます。
PUT /api/attemptsTreasure Workflow API: API クライアントはレスポンスで失敗を確認し、自身でリクエストを再試行する必要があります。
- プールについて: アテンプトがプールに割り当てられる仕組み。
- プールを管理する: プールの並行実行数の上限を変更してスロットを空けます。
- プールのユースケース: プール、ルール、キューイングを組み合わせた実例。