Po uruchomieniu FileSystemWatcher - Pula wątków lub dedykowany wątek?

Question

Mam zamiar wdrożyć archetypowe rozwiązanie FileSystemWatcher. Mam katalog do monitorowania tworzenia plików i zadanie wysysania utworzonych plików i wstawienia do bazy danych. Z grubsza będzie to wymagało odczytania i przetworzenia 6 lub 7 plików tekstowych o wartości 80 znaków, które pojawiają się z szybkością 150 ms w seriach, które pojawiają się co kilka sekund, a rzadko trzeba też przetworzyć plik binarny o wielkości 2 MB. Najprawdopodobniej będzie to proces 24/7.

Z tego, co przeczytałem na temat obiektu FileSystemWatcher, lepiej jest uporządkować jego zdarzenia w jednym wątku, a następnie wycofać/przetworzyć je w innym wątku. Dylemat, jaki mam teraz, byłby lepszym mechanizmem tworzenia wątku, który przetwarza dane. Wybory widzę to:

1. Za każdym razem dostaję zdarzenie FSW ręcznie utworzyć nowy wątek (Tak wiem .. głupiego architekturę, ale musiałem to powiedzieć).

2. Rzuć przetwarzanie w puli wątków CLR ilekroć pojawia się zdarzenie FSW

3. przy starcie, tworzenie dedykowanego drugą nitkę na przetwarzanie i wykorzystanie modelu producent/konsumentów do obsługi pracy. Główny wątek wpisuje żądanie, a drugi wątek usuwa go i wykonuje pracę.

mam tendencję w kierunku trzeciej metody jako preferowana co wiem zawsze będzie wymagane nić praca - a także prawdopodobnie bardziej, że nie mam wyczucie puli wątków.

Answer 1

Jeśli wiesz że zawsze będzie wymagany drugi wątek, a także wiedzieć że nigdy nie będziesz potrzebować więcej niż jednego wątku roboczego, a następnie trzy opcja jest wystarczająco dobre.

Answer 2

Pamiętaj, że FileSystemWatcher może ominąć zdarzenia, nie ma gwarancji, że dostarczy wszystkie określone zdarzenia, które się wydarzyły. Twój projekt utrzymywania pracy przez wątek otrzymujący zdarzenia do minimum, powinien zmniejszyć szanse na to, ale nadal jest to możliwe, biorąc pod uwagę wielkość bufora zdarzeń skończonych (osiąga 64 KB).

Zdecydowanie polecam opracowanie zestawu testów torturowania, jeśli zdecydujesz się na użycie FileSystemWatcher.

Podczas naszych testów napotkaliśmy problemy z lokalizacjami sieci, których zmiana InternalBufferSize nie została rozwiązana, ale kiedy napotkaliśmy ten scenariusz, nie otrzymaliśmy również powiadomień o błędach.

W ten sposób opracowaliśmy nasz własny mechanizm odpytywania, stosując Directory.GetFiles, a następnie porównując stan zwróconych plików z wcześniejszym stanem odpytywania, zapewniając, że zawsze mieliśmy dokładną deltę.

Oczywiście wiąże się to ze znacznymi kosztami, które mogą okazać się niewystarczające.

Answer 3

Trzecia opcja jest najbardziej logiczna.

W odniesieniu do FSW brakuje niektórych wydarzeń plików, I wdrożone następująco: 1) FSW przedmiot, który pożary na FileCreate 2) tmrFileCheck, kleszcze = 5000 (5 sekund) - Rozmowy tmrFileChec_Tick

Gdy zdarzenie FileCreate nastąpi, jeżeli == tmrFileCheck.Enabled (fałsz) następnie tmrFileCheck.Start()

ten sposób, po 10 sekundach tmrFileCheck_Tick pożary a) tmrFileCheck.Stop() b) CheckForStragglerFiles

Z testów, które przeprowadziłem, działa to skutecznie tam, gdzie są tworzone pliki < 100 na minutę.

Wariant polega jedynie na tym, że zegar będzie miał tylko NN sekund i przemieści katalog (y) dla plików zrzucających.

Innym wariantem jest zatrudnienie mnie do naciśnięcia klawisza F5, aby odświeżyć okno i zadzwonić do ciebie, gdy istnieją pliki maruderów; tylko sugestia. :-P