ストーム最大噴出口保留中
これは、Stormの最大スパウト保留がどのように機能するかに関する質問です。私は現在、ファイルを読み取り、ファイルの各行に対してタプルを発行する注ぎ口を持っています（Stormがファイルを処理するための最良の解決策ではないことは知っていますが、この問題に対する選択肢はありません）。
_topology.max.spout.pending_を50kに設定して、処理するトポロジに入るタプルの数を抑制します。ただし、この数値はトポロジに影響を与えていません。ファイル内のすべてのレコードが毎回発行されているのがわかります。私の推測では、これは、ファイル内のすべてのレコードを出力するnextTuple()メソッドにあるループが原因である可能性があります。
私の質問は、_topology.max.spout.pending_に達したときに、StormがSpoutタスクのnextTuple()の呼び出しを停止するだけですか？これは、メソッドが呼び出されるたびに1つのタプルのみを発行する必要があることを意味しますか？
丁度！ Stormは次のコマンドでのみ注ぎ口を制限できるため、最初の次のコマンドを受信したときにすべてを送信すると、Stormが注ぎ口を絞る方法はありません。
Storm開発者は、1つのnextコマンドで1つのタプルを発行することをお勧めします。 Stormフレームワークは、「最大スパウト保留」要件を満たすために、必要に応じてスパウトを抑制します。多数のタプルを放出している場合は、放出を最大で最大注ぎ口の10分の1までバッチ処理して、ストームにスロットルする機会を与えることができます。
ストームトポロジには、最大スパウト保留パラメータがあります。トポロジの最大スパウト保留値は、トポロジ構成yamlファイルの「topology.max.spout.pending」設定を介して構成できます。この値は、どの時点でもストームトポロジで飛行できるタプルの数、つまり、まだ確認または失敗していないタプルの数に制限を設定します。このパラメーターの必要性は、StormがZeroMQを使用して、あるタスクから別のタスクにタプルをディスパッチするという事実に由来します。 ZeroMQのコンシューマー側がタプルレートに追いつくことができない場合、ZeroMQキューが蓄積し始めます。最終的に、タプルは注ぎ口でタイムアウトになり、トポロジに再生されるため、キューにさらに圧力がかかります。この病理学的障害のケースを回避するために、Stormでは、ユーザーがトポロジ内で飛行中のタプルの数に制限を設けることができます。 この制限は、トポロジレベルではなく、スパウトタスクごとに有効になります。（ ソース ）スパウトの場合信頼性が低い、つまりタプルでメッセージIDを発行しない場合、この値は効果がありません。 Stormユーザーが継続的に直面する問題の1つは、この最大注ぎ口保留パラメーターの正しい値を考え出すことです。値が非常に小さいとトポロジが不足しやすくなり、値が十分に大きいとトポロジが過負荷になり、障害やリプレイが発生する可能性があります。ユーザーは、自分に最適な値を見つけるために、最大スパウト保留値が異なるトポロジ展開を数回繰り返す必要があります。
1つの解決策は、nextTupleメソッドの外部に入力キューを構築することであり、nextTupleで行う唯一のことは、キューをポーリングして発行することです。複数のファイルを処理している場合、nextTupleメソッドは、キューのポーリング結果がnullかどうかも確認し、nullの場合は、キューに入力されているソースファイルをアトミックにリセットする必要があります。