1

I am using the .NET filesystemwatcher class to monitor files on disk.

I'm writing a program that is supposed to watch a shared folders from numerous remote machines. I've been testing a bunch and have confirmed that I can get events from shared folders (i.e. "\MACHINE1\C\Testing"). I have a pretty good grasp on what the notify filter, raise event enable, and callback requirements are.

I cannot find any note of a limit to how many watchers you can create in the documentation. However, from my testing, I've found that I can only create 63 when monitoring remote file system (there is no such limit when monitoring the local file system). Creating further watchers after that doesn't error, but the later watchers don't generate events either! And if I want re-run the program, I cannot make any (since I have already made the limit) until I close the IDE and reopen it. That makes me think that something is not being disposed of properly, but the fact that I can only make 63 on the first run makes me think that improper disposal is not the cause.

Does anyone have some insight on this? The client is hoping to monitor on the order of 100s of machines and I'd prefer not to have to use numerous servers/app instances to do this.

Note: I would post code here, but it is being made in LabVIEW - a gross misuse of what LabVIEW is for, I know, but here I am.

VI for calling the .NET code

mikemikemikemikemike
  • 21
  • 5
  • I don't know why you think it's a gross misuse. People use LV for entire plant operations. :-) But, regardless, you can post LV code as PNGs from your VIs. Since you're brand new, you can post links to the images and one of us with higher rank will edit your post to inline the images. – srm May 14 '21 at 03:44
  • Also, is filesystemwatcher some sort of toolkit or add-on to LabVIEW? It isn't something I can find in any of the core libraries. – srm May 14 '21 at 03:45
  • Hi srm, thanks for your comment. The filesystemwatcher is a windows class for capturing file events. See here (https://learn.microsoft.com/en-us/dotnet/api/system.io.filesystemwatcher?view=net-5.0). I wasn't sure if there were many LabVIEW people on here, but I felt the problem was more related to the windows functions than LabVIEW. Plus NI forums appeared to be down in my area. I'll try to attach both some snippets and VI's later today. Thanks! Note -- My stack overflow account is new, but I've actually had my CLD for 4 years now... – mikemikemikemikemike May 15 '21 at 17:11
  • I just discovered that I'm not limited to 63 when creating the filewatchers on my local PC, only when I am trying to monitor remote folders. Anyway, I put some sample VIs (backsaved to 2012) and snippets (2019) in dropbox. VIs: https://www.dropbox.com/sh/lele95b7xfla710/AABmBaLEZ1x8KwQv7LMYsT5ya?dl=0 Create File Watcher snippet: https://www.dropbox.com/s/ci9ckt59yqvgfap/Create%20File%20Watcher%20snippet.png?dl=0 Callback event snippet: https://www.dropbox.com/s/smgmqvfqm06gcdl/Callback%20Event%20snippet.png?dl=0 Let me know if that works. – mikemikemikemikemike May 15 '21 at 17:50
  • I updated your question, notably I added the .NET tag. I hope this gets more visibility. I seriously thought about removing the LabVIEW tag because it feels strongly unimportant to your question. But I left it... you may re-evaluate. – srm May 16 '21 at 04:44
  • 1
    Does this answer your question? [What are practical limits on the number of FileSystemWatcher instances a server can handle?](https://stackoverflow.com/questions/10195317/what-are-practical-limits-on-the-number-of-filesystemwatcher-instances-a-server) – Lance U. Matthews May 16 '21 at 06:18
  • @srm - thanks for adding the .NET tag, that's a good idea. I'll leave the LV tag for now, since there are links to VIs and such in my comment. – mikemikemikemikemike May 17 '21 at 05:15
  • @LanceU.Matthews - that seems pretty on target, very similar project scope. It's funny that didn't show up in my searches before (using keywords like "FileSystemWatcher", "instances", and "limits")! Hopefully it will solve it for me, too. I will update here if it does. – mikemikemikemikemike May 17 '21 at 05:17
  • Hi @LanceU.Matthews. So I read through that thread. Seems like the forefront issue was that the devs buffer was too big for creating network FSWs. In my app, I'm leaving it at the default, 8kB (ignore screenshot above), and still having the issue. New development though! It turns out that 63 is not the limit of FSWs I can create per application instance, but per remote machine... I set up 3 remote machines and FSWs for 50 folders on each, and they all worked! But if I try to run it again, only 13 on each worked (63 is still the magic number). – mikemikemikemikemike May 17 '21 at 23:19
  • This wouldn't be too terrible of a problem, except that there is NO error returned when the FSW is "invalid". I would have to keep count and force my app to restart itself once it gets to 63 - yuck. I only plan on watching one folder per machine, but if the machine goes offline and comes back, I have to re-create the FSW or it doesn't work, so eventually I could reach this limit. – mikemikemikemikemike May 17 '21 at 23:21
  • You didn't say what you are doing for disposing. I don't know the details, but I'm assuming you would need to properly unregister and destroy the relevant events, call the relevant dispose methods, close all reference, etc. Also, calling the GC.Collect method might be a good idea, as that helps with .NET callbacks which are locked when you stop running your code. – Yair May 18 '21 at 07:06
  • Here's a snippet of closing the references: https://imgur.com/9Vz2snQ I did see someone complain about .NET callback events not being closed and using GC.collect(). I'm not familiar with that but I'll see if I can try it. – mikemikemikemikemike May 19 '21 at 23:31
  • Tried adding GC.collect(). It didn't allow me to make more than 63 instances, and also didn't solve the issue of having to close the dev environment in order to create any more after the first 63. – mikemikemikemikemike May 20 '21 at 15:01

0 Answers0