Too many Filewatches!
-
Hello All! I am really stumped on this. So I have a server/client app, with SQL as a backend. The client program has it's forms come up by the server. That where I use the FileWatch process. Works pretty well, and fast. I creat a file from the server on server, the client flewatch see that file, and open up a form. A timer on the form closes after a few some time. The file the server creates, gets deleted. I'm sure this isn't the best way, but it works pretty well, except now. I can only run up to like six or seven at a time. Anyone of them will work, but not all at the same time. My server is created the files just fine, so the problem is with the client side. I don't get a warning or an error. The watch process just doesn't run. So here is a sample of the code. Declaring it,
Public FggWatch As New FileSystemWatcherI have this in my form load event. I also tried to put it in IntilizedComponet.AddHandler FggWatch.Created, AddressOf FggWatch_Created FggWatch.Path = (TempFileSetting) FggWatch.Filter = "*.fgg" FggWatch.IncludeSubdirectories = False FggWatch.EnableRaisingEvents = TrueAnd then here is what happen after the file gets taggedPrivate Sub FggWatch_Created(ByVal sender As Object, ByVal e As System.IO.FileSystemEventArgs) Dim frmFgg As New frmFggWn Sound.PlayWaveResource("ding.wav") frmFgg.ShowDialog() End SubIt worked fine for weeks, then all of sudden! You know. Now keep in mind I have 13 of thees little gems, the only difrence in the file names, and a diffrent form get displayed. Thanks!! Rudy -
Hello All! I am really stumped on this. So I have a server/client app, with SQL as a backend. The client program has it's forms come up by the server. That where I use the FileWatch process. Works pretty well, and fast. I creat a file from the server on server, the client flewatch see that file, and open up a form. A timer on the form closes after a few some time. The file the server creates, gets deleted. I'm sure this isn't the best way, but it works pretty well, except now. I can only run up to like six or seven at a time. Anyone of them will work, but not all at the same time. My server is created the files just fine, so the problem is with the client side. I don't get a warning or an error. The watch process just doesn't run. So here is a sample of the code. Declaring it,
Public FggWatch As New FileSystemWatcherI have this in my form load event. I also tried to put it in IntilizedComponet.AddHandler FggWatch.Created, AddressOf FggWatch_Created FggWatch.Path = (TempFileSetting) FggWatch.Filter = "*.fgg" FggWatch.IncludeSubdirectories = False FggWatch.EnableRaisingEvents = TrueAnd then here is what happen after the file gets taggedPrivate Sub FggWatch_Created(ByVal sender As Object, ByVal e As System.IO.FileSystemEventArgs) Dim frmFgg As New frmFggWn Sound.PlayWaveResource("ding.wav") frmFgg.ShowDialog() End SubIt worked fine for weeks, then all of sudden! You know. Now keep in mind I have 13 of thees little gems, the only difrence in the file names, and a diffrent form get displayed. Thanks!! RudyRudy I am a little vague on what you are trying to do but the filewatcher can become unstable over time. So first off do you run the application that is hosting the filewatcher as a windows application or as a service? Why are you running so many filewatchers?
-
Rudy I am a little vague on what you are trying to do but the filewatcher can become unstable over time. So first off do you run the application that is hosting the filewatcher as a windows application or as a service? Why are you running so many filewatchers?
Hi Kevin! It's running as a windows application. Basicly I need the server to control the client software 90% of the time, at will. For example, when a button on the server is pressed, form 1 opens on the client. When button 2 on the server is pressed, a timer starts on the client. The user at the client has very little control. I have tried .Net Remoting, but havent been very successful at it. I thought about creating events that stop and start the filewatches at certain times. Just haven't gone down that road yet. Why would a filewatcher become unstable over time? Thanks! Rudy:)
-
Hi Kevin! It's running as a windows application. Basicly I need the server to control the client software 90% of the time, at will. For example, when a button on the server is pressed, form 1 opens on the client. When button 2 on the server is pressed, a timer starts on the client. The user at the client has very little control. I have tried .Net Remoting, but havent been very successful at it. I thought about creating events that stop and start the filewatches at certain times. Just haven't gone down that road yet. Why would a filewatcher become unstable over time? Thanks! Rudy:)
Most of my experience with FileWatchers is in the services realm I just don't use them that much in windows applications so there may be differences. To be precise I believe the Filewatchers become unstable because of the code they are running in. The threading in the Filewatcher can cause other contention issues in the application particularly when you are running timers also. I periodically recycle the services and this seems to solve the issue but that is not good design. I am more prone to running them inside of their own class now and tearing that down and re instantiating it periodically disposing of all resources. I also try to use as few filewatchers as possible and change where they are pointing in code so I have fewer moving parts to keep track of. So far it has been pretty stable but this is in windows services not windows applications which should not be an issue but they are much less complicated. What I have done is 180 degrees from what you are doing so there are clear differences. I use logging quite a bit to track down issues with timers and filewatchers as well as the performance monitoring tools which has been helpful.
-
Most of my experience with FileWatchers is in the services realm I just don't use them that much in windows applications so there may be differences. To be precise I believe the Filewatchers become unstable because of the code they are running in. The threading in the Filewatcher can cause other contention issues in the application particularly when you are running timers also. I periodically recycle the services and this seems to solve the issue but that is not good design. I am more prone to running them inside of their own class now and tearing that down and re instantiating it periodically disposing of all resources. I also try to use as few filewatchers as possible and change where they are pointing in code so I have fewer moving parts to keep track of. So far it has been pretty stable but this is in windows services not windows applications which should not be an issue but they are much less complicated. What I have done is 180 degrees from what you are doing so there are clear differences. I use logging quite a bit to track down issues with timers and filewatchers as well as the performance monitoring tools which has been helpful.