Después de incendios FileSystemWatcher - Grupo de subprocesos o hilo dedicado?

Question

Estoy a punto de implementar la solución arquetípica FileSystemWatcher. Tengo un directorio para supervisar las creaciones de archivos y la tarea de absorber archivos creados e insertarlos en un DB. Aproximadamente esto implicará leer y procesar 6 o 7, 80 archivos de texto de char que aparecen a una velocidad de 150 ms en ráfagas que ocurren cada dos segundos, y raramente también se tendrá que procesar un archivo binario de 2 MB. Esto probablemente sea un proceso 24/7.

Por lo que he leído sobre el objeto FileSystemWatcher es mejor poner en cola sus eventos en un hilo y luego dequeue/procesarlos en otro hilo. El dilema que tengo ahora es cuál sería el mejor mecanismo de creación del hilo que procesa. Las opciones que puedo ver son:

1. Cada vez que tengo un evento FSW puedo crear manualmente un nuevo hilo (sí lo sé .. arquitectura estúpida, pero tenía que decirlo).

2. Tire el procesamiento en el grupo de subprocesos CLR cada vez que tengo un evento FSW

3. En el arranque, crear un segundo hilo dedicado para la transformación y la utilización de un modelo productor/consumidor para manejar el trabajo. El hilo principal pone en cola la solicitud y el segundo hilo lo quita y realiza el trabajo.

estoy tendiendo hacia el tercer método como el preferido que yo sepa siempre será necesario el hilo de trabajo - y también, probablemente, más aún porque no tengo ni idea de la agrupación de hebras.

Answer 1

Si sabe que siempre será necesario el segundo hilo, y también se sabe que nunca necesitará más de un subproceso de trabajo, entonces la opción tres es suficiente.

Answer 2

Solo tenga en cuenta que FileSystemWatcher puede perder eventos, no hay garantía de que entregará todos los eventos específicos que se hayan producido. El diseño de mantener el trabajo realizado por los eventos de recepción de subprocesos a un mínimo, debería reducir las posibilidades de que eso ocurra, pero todavía existe la posibilidad, dado el tamaño de búfer de evento finito (alcanza un máximo de 64 KB).

Recomiendo encarecidamente desarrollar una batería de pruebas de tortura si decide utilizar FileSystemWatcher.

En nuestras pruebas, encontramos problemas con las ubicaciones de red, que el cambio de InternalBufferSize no se corrigió, sin embargo, cuando encontramos este escenario, tampoco recibimos notificaciones de eventos de error.

Por lo tanto, desarrollamos nuestro propio mecanismo de sondeo para hacerlo, usando Directory.GetFiles, seguido por la comparación del estado de los archivos devueltos con el estado previamente sondeado, asegurando que siempre tengamos un delta preciso.

Por supuesto, esto tiene un costo sustancial en rendimiento, que puede no ser lo suficientemente bueno para usted.

Answer 3

La tercera opción es la más lógica.

En lo que respecta a FSW faltan algunos eventos de archivos, he implementado este: 1) FSW objeto que dispara en FileCreate 2) tmrFileCheck, garrapatas = 5000 (5 segundos) - Llamadas tmrFileChec_Tick

Cuando el evento FileCreate se produce, si (tmrFileCheck.Enabled == false), entonces tmrFileCheck.Start()

De esta manera, después de 10 segundos incendios tmrFileCheck_Tick que a) tmrFileCheck.Stop() b) CheckForStragglerFiles

De las pruebas que he ejecutado, esto funciona efectivamente donde hay un < 100 archivos creados por minuto.

Una variante es meramente tener un temporizador marcar NN segundos y barrer el directorio (s) para archivos rezagados.

Otra variante es contratarme para presionar F5 para actualizar la ventana y llamar cuando hay archivos rezagados; sólo una sugerencia. :-P