5

典型的な FileSystemWatcher ソリューションを実装しようとしています。ファイルの作成を監視するディレクトリと、作成されたファイルを吸い上げてDBに挿入するタスクがあります。大まかに言えば、これには、数秒ごとに発生するバーストで 150 ミリ秒のレートで表示される 6 または 7、80 文字のテキスト ファイルの読み取りと処理が含まれ、まれに 2MB のバイナリ ファイルも処理する必要があります。これは、ほとんどの場合、24 時間年中無休のプロセスです。

FileSystemWatcher オブジェクトについて読んだことから、そのイベントをあるスレッドでキューに入れ、別のスレッドでそれらをデキュー/処理する方が良いでしょう。私が今持っている困惑は、処理を行うスレッドのより良い作成メカニズムは何であるかということです。私が見ることができる選択肢は次のとおりです。

  1. FSW イベントを取得するたびに、手動で新しいスレッドを作成します (ええ、わかっています.. ばかげたアーキテクチャですが、言わなければなりませんでした)。

  2. FSW イベントを取得するたびに、CLR スレッド プールで処理をスローします。

  3. 起動時に、処理専用の 2 番目のスレッドを作成し、プロデューサー/コンシューマー モデルを使用して作業を処理します。メイン スレッドが要求をキューに入れ、2 番目のスレッドが要求をキューから取り出して作業を実行します。

ワークスレッドが常に必要になることがわかっているため、3番目の方法を優先する傾向があります。また、スレッドプールの感覚がないため、おそらくもっとそうです。

4

3 に答える 3

3

3番目のオプションは最も論理的です。

いくつかのファイルイベントが欠落しているFSWに関して、私はこれを実装しました：1）FileCreateで起動するFSWオブジェクト2）tmrFileCheck、ティック= 5000（5秒）-tmrFileChec_Tickを呼び出します

FileCreateイベントが発生したときに、（tmrFileCheck.Enabled == false）の場合、tmrFileCheck.Start（）

このようにして、10秒後にtmrFileCheck_Tickが起動します。a）tmrFileCheck.Stop（）b）CheckForStragglerFiles

私が実行したテストの中で、これは1分あたり100未満のファイルが作成されている場合に効果的に機能します。

変形は、単にNN秒ごとにタイマーティックを設定し、ストラグラーファイルのディレクトリをスイープすることです。

もう1つの方法は、F5キーを押してウィンドウを更新し、ストラグラーファイルがある場合に電話をかけるように私を雇うことです。ただの提案です。:-P

于 2012-10-18T16:36:25.493 に答える
3

2番目のスレッドが常に必要であり、複数のワーカースレッドが必要になることはないこともわかっている場合は、オプション3で十分です。

于 2010-02-22T01:02:51.400 に答える
2

FileSystemWatcher はイベントを見逃す可能性があることに注意してください。発生したすべての特定のイベントを配信する保証はありません。イベントを受信するスレッドによって実行される作業を最小限に抑えるように設計すると、その可能性は低くなりますが、有限のイベント バッファー サイズ (上限は 64KB) を考えると、まだ可能性があります。

FileSystemWatcher を使用する場合は、一連の拷問テストを開発することを強くお勧めします。

私たちのテストでは、InternalBufferSize を変更しても修正されないというネットワーク ロケーションの問題が発生しましたが、このシナリオに遭遇したとき、エラー イベント通知も受信しませんでした。

そのため、Directory.GetFilesを使用して独自のポーリング メカニズムを開発し、返されたファイルの状態を以前にポーリングした状態と比較して、常に正確な差分を取得できるようにしました。

もちろん、これにはかなりのパフォーマンス コストがかかるため、十分ではない可能性があります。

于 2010-02-22T02:14:23.283 に答える