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

受信チャネルアダプターを構成するときは、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 を介して）変更される可能性があります。

バージョン 7.0 以降、AbstractInboundFileSynchronizer は maxFetchSize スライスを適用した後、フィルタリングされた Session.list(remoteDirectory) をキャッシュします。AbstractInboundFileSynchronizer.transferFilesFromRemoteToLocal() メソッドのロジックは次のとおりです。

  • maxFetchSize > 0 の場合、キャッシュ周辺で作業が行われる際に、異なるスレッド間の競合状態を回避するため、remoteDirectory に対してロックが取得されます。以降の同期処理はすべてメモリ内にキャッシュされた残りのデータのみを処理するため、パフォーマンスの低下は最小限に抑えられます。

  • remoteDirectory のキャッシュエントリがない場合、Session.list(remoteDirectory) が呼び出され、返されたすべての リモートファイルがフィルター処理されます。

  • フィルタリングされた結果は maxFetchSize にスライスされます。

  • これらのファイルエントリはローカルディレクトリに転送されます。

  • フィルタリングされた残りの リモートファイルは、後で同期するためにキャッシュされます。

  • remoteDirectory のキャッシュエントリがある場合、そのようなリストは maxFetchSize にスライスされ、ローカルディレクトリへの転送のために反復されます。

  • いずれかの転送が失敗した場合、filter は失敗したリモートファイルからリセットされます。キャッシュも削除されるため、次回の同期はクリーンな状態から開始されます。

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