Hmm, that buffer must be populated quite fast be the system, I suppose offloading to a queue and increasing the internal buffer, will get you close but there is no way to guarantee. Oh well :(. To make it completely bullet proof your probably going to have to not rely on the filesystemwatcher and instead go to a polling approach, that moves the file to process out of the folder then simply poll every so often for new files.
Justin Harrell Vice President Development Aciss Systems Inc. -----Original Message----- From: Scott Boston [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 4:44 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Problem with Service and File System Watcher Unfortunately it doesn't guarantee no overflows completely, although passing the processing off to a queue certainly helps. In my application I still have to have watch for overflows even though the files to be processed are loaded into a queue, and then subsequently processed on another thread, usually when somewhere over 300 files get dumped into the folder at once. -----Original Message----- From: The DOTNET list will be retired 7/1/02 [mailto:[EMAIL PROTECTED]] On Behalf Of Justin Harrell Sent: Wednesday, June 12, 2002 12:12 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Problem with Service and File System Watcher Although I made it sound complicated, if your new to multithreading, its really not. If you use the System.Threading.ThreadPool.QueueUserWorkItem and put your process function in as the workitem right in the created event, although you don't have as much control of the threads in the thread pool as if you made them yourself, it's a snap to do and should gurantee no overflows. Justin Harrell Vice President Development Aciss Systems Inc. -----Original Message----- From: Don Davis [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 2:53 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Problem with Service and File System Watcher Scott, Thanks!! that was it. Now getting buffer errors. Justin, sounds like your on to something with this thought about threading. (somthing i'm not up to speed on yet). Digging through my code, I found some areas where it can be tweaked for better performance. I was able to make room in the buffer by dropping LastWrite from the filter lists. Between that and my improvements I'll make this afternoon, I'm hoping this will "run for now". May try bumping the buffer size by a bit (understand that this is "bad" practice). I'll get this going then I'll come back to Justin's suggestion. Steve, thanks for the reminder about windows folder limits. I believe we have encountered this one before. One of the things our process does is move the file. We also have a separate process that archives and deletes "old" files. Again, thanks all, for the help. Just what we needed!! Regards, Don You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
