После пожаров в FileSystemWatcher - Пул потоков или Специализированный поток?
Я собираюсь реализовать типичное решение FileSystemWatcher. У меня есть каталог для контроля для созданий файла и задачи всасывания созданных файлов и вставки в DB. Примерно это включит чтение и обработку 6 или 7, 80 символьных текстовых файлов, которые появляются на уровне 150 мс в пакетах, которые происходят каждые несколько секунд, и редко двоичный файл 2 МБ должен будет также быть обработан. Это, скорее всего, будет процессом 24/7.
Из того, что я читал об объекте FileSystemWatcher, что лучше ставить в очередь свои события в одном потоке и затем исключить их из очереди/обработать в другом потоке. Затруднительное положение, которое я имею прямо сейчас, - то, что было бы лучшим механизмом создания потока, который делает обработку. Выбор, который я вижу:
Каждый раз, когда я получаю событие FSW, я вручную создаю новый поток (да, я знаю.. глупая архитектура, но я должен был сказать это).
Бросьте обработку в пул потоков CLR каждый раз, когда я получаю событие FSW
На запуске создайте специализированный второй поток для обработки и используйте модель производителя/потребителя для обработки работы. Основной поток ставит в очередь запрос, и второй поток исключает его из очереди и выполняет работу.
Я склоняюсь к третьему методу как предпочтительный, поскольку я знаю, что поток работы будет всегда требоваться - и также вероятно, больше, потому что я имею, не сопереживают пулу потоков.
2 ответа
Если вы знаете , что второй поток потребуется всегда, и вы также знаете , что вы никогда не нужно больше одного рабочего потока, тогда вариант три достаточно хорош.
Просто имейте в виду, что FileSystemWatcher может пропускать события, нет гарантии, что он доставит все конкретные события, которые произошли. Ваш дизайн, сводящий к минимуму работу, выполняемую потоком, принимающим события, должен снизить вероятность того, что это произойдет, но это все еще возможность, учитывая конечный размер буфера событий (максимум 64 КБ).
Я настоятельно рекомендую разработать батарею тестов на пытки, если вы решите использовать FileSystemWatcher.
В нашем тестировании мы столкнулись с проблемами с сетевым расположением, которые не удалось устранить с помощью изменения InternalBufferSize, но когда мы столкнулись с этим сценарием, мы также не получили уведомления об ошибках.
Таким образом, мы разработали для этого наш собственный механизм опроса, используя Directory.GetFiles , с последующим сравнением состояния возвращенных файлов с ранее опрошенным состоянием, гарантируя, что у нас всегда есть точная дельта.
Конечно, это связано со значительными потерями в производительности, что может быть недостаточно для вас.