受信チャネルアダプター: リモートファイルフェッチの制御

受信チャネルアダプターを構成するときは、2 つのプロパティを考慮する必要があります。max-messages-per-poll は、すべてのポーラーと同様に、各ポーリングで送信されるメッセージの数を制限するために使用できます（構成された値を超える準備ができている場合）。max-fetch-size （バージョン 5.0 以降）は、一度にリモートサーバーから取得するファイルの数を制限できます。

次のシナリオでは、開始状態が空のローカルディレクトリであると想定しています。

max-messages-per-poll=2 および max-fetch-size=1: アダプターは、1 つのファイルを取り出して発行し、次のファイルを取り出して発行します。その後、次のポーリングまでスリープします。
max-messages-per-poll=2 および max-fetch-size=2）: アダプターは両方のファイルをフェッチしてから、それぞれを発行します。
max-messages-per-poll=2 および max-fetch-size=4: アダプターは、最大 4 つのファイル（使用可能な場合）をフェッチし、最初の 2 つを発行します（少なくとも 2 つある場合）。次の 2 つのファイルは、次のポーリングで発行されます。
max-messages-per-poll=2 および max-fetch-size が指定されていない: アダプターは、すべてのリモートファイルをフェッチし、最初の 2 つを発行します（少なくとも 2 つある場合）。後続のファイルは、後続のポーリングで発行されます（一度に 2 つ）。すべてが消費されると、リモートフェッチが再度試行され、新しいファイルが取得されます。

アプリケーションの複数のインスタンスをデプロイするときは、小さな max-fetch-size を設定して、1 つのインスタンスがすべてのファイルを「取得」し、他のインスタンスを枯渇させないようにすることをお勧めします。

max-fetch-size のもう 1 つの用途は、リモートファイルのフェッチを停止するが、すでにフェッチされているファイルの処理を続行したい場合です。MessageSource で maxFetchSize プロパティを (プログラム的に、JMX 経由、または制御バス経由で) 設定すると、アダプターによるさらなるファイルのフェッチが効果的に停止されますが、ポーラーは以前にフェッチされたファイルに対するメッセージの出力を継続できるようになります。プロパティの変更時にポーラーがアクティブな場合、変更は次のポーリングで有効になります。

バージョン 5.1 以降、シンクロナイザーに Comparator<?> を提供できます。これは、maxFetchSize でフェッチされるファイルの数を制限するときに役立ちます。

バージョン 6.4 以降、AbstractRemoteFileStreamingMessageSource には、処理されていないリモートファイルの参照をキャッシュから削除するための便利な clearFetchedCache() API が追加されました。ポーリング構成では 1 サイクルですべての参照を処理できないため、参照はキャッシュに残ります。また、ターゲット SessionFactory は、ポーリングサイクル間で (たとえば、RotatingServerAdvice を介して) 変更される可能性があります。

FileListFilter 構成に関する情報については、一般的な SFTP 受信チャネルアダプターの章も参照してください。