序章
ファイルシステムのサブツリーに対して反復子を作成する必要があります (たとえば、フォルダーを指定すると、内部に含まれるすべてのファイルを深さ優先検索の順序で、nextメソッド呼び出しごとに 1 つずつ返す反復子)。
サブツリーの内容は、時間の経過とともに変化する可能性があります。たとえば、反復がまだ進行している間に、新しいサブフォルダーとファイルが作成され、既存のものの一部が削除される可能性があります (可能性が高い)。
幸いなことに、次の条件が許容されます。
実装では、新しく作成されたファイル (反復の開始後に作成されたファイルなど) とフォルダー (およびそれらのフォルダー内のファイル)、またはそれらの一部だけをスキップできます (ただし、スキップしない方がよいでしょう)。
実装では、削除されたファイル (たとえば、存在しないが反復の開始時に存在していたファイル) を一覧表示することができます (しかし、そうしない方がよいでしょう)。
動機
これらの決定の背後にある理論的根拠をよりよく理解していただくために、アプリケーション全体について簡単に説明したいと思います。
プロデューサー/コンシューマーのようなアプリケーションです。Web サービス (プロデューサ) は、ファイルを受け取り、サブツリー階層のどこかにあるローカル ファイル システムに格納します。
別のアプリケーション (消費者) がこれらのファイルを処理します。数分ごとにCRONを介して定期的に呼び出されます。起動すると、サブツリーをクロールし、すべてのドキュメントを見つけて、それらを処理するために引き渡します (関連する場合は、さらに別のアプリケーションに)。ドキュメントが処理されると、ローカル ファイル システムから削除されます。
問題は、プロデューサーとコンシューマーが同時に実行されることです。さらに、コンシューマ アプリケーションの複数のインスタンスが同時に実行されている場合もあります。たとえば、コンシューマーがサブツリーをクロールしている間に、新しいドキュメントが作成されたり、既存のドキュメントが削除されたりすることがあります。サブディレクトリの構造も変更される可能性があります。
クローラーは数分ごとに定期的に起動されるため、その時点で使用可能なすべてのドキュメント (特に、コンシューマーの実行中に生成されるドキュメント) を消費するかどうかは問題ではありません。生成されたドキュメントが最終的に消費されることだけが重要です (かなり短い遅延で)。それが、上記のリラックスした条件の由来です。
可能な解決策
最初は、起動時にサブツリーのスナップショットをメモリに作成し (処理するドキュメントのリストなど)、それらを反復処理することを考えました。私の他の投稿を参照してください。しかし、階層は非常に大きくなる可能性があり (数時間に数万のドキュメントが処理されることさえあります)、このアプローチには許容できないパフォーマンス要求 (メモリと速度) があるのではないかと考えていました。
そのようなイテレータをどのように実装しますか?
ご協力いただきありがとうございました。長い投稿で申し訳ありません。