First off, I realize that this request is a little unusual. Two times in the last 3 days, a multicast broadcast was kicked off on my network by accident and following each of those instances we have observed that Opus 10 64-bit (running on Windows Server 2008 R2) is unable to detect changes to any folder contents (local and network). Windows Explorer does continue to detect both local and network file changes. Does this make any sense? Is there something about the way that Opus is detecting file changes that could cause it to collapse after a large network IP broadcast?
Is there any way short of a reboot to recover the functionality of this Opus feature?
I can't think of any reason why a multicast broadcast should have this effect, and I know I have used multicast at times on my own machine without noticing any issues.
If you fully exit Opus and re-run it does it start detecting changes again?
Thanks for the reply. I later noticed that each instance of Opus that was running at the time started consuming more than 1 gb of ram and didn't release any memory. Even new instances consumed large amounts of ram. Once ALL of them were closed New Opus sessions started functioning as usual.
There is no doubt, in my mind, that the broadcast (of 10+ gb of data) led to the problem. It happened immediately after ach each occurrence. Does it make more sense with that volume of data?
Opus doesn't run a server or listen on any ports (except when using FTP PASV) so it wouldn't be receiving the data directly, but I guess it's possible a third-party extension may be loaded in the Opus process and receiving the data. It seems rather odd though.
Thanks, again. How do I determine what plugins might be being utilized in Opus? The only one I know of already would be Winzip.
The data wasn't being targeted at the server on which Opus was running but the nic on the server would have been exposed to the Ethernet frames sine they were being sent to the entire network. How does Opus detect changes to network folders? It's curious to me that detecting file changes was pretty much the only feature that was affected.
I forgot to mention that each Opus session was also putting a steady
How do I determine what plugins might are being utilized in Opus? The only one I know of off hand would be Winzip and perhaps Adobe Acrobat. Is it as simple as anything that shows up in the right click menu?
The data wasn't being targeted at the server on which Opus was running but the nic on the server would have been exposed to the Ethernet frames sine they were being sent to the entire network.
How does Opus detect changes to network folders? It's curious to me that detecting file changes was pretty much the only feature that was affected.
I forgot to mention that each Opus session was also putting a steady albeit low load on the processor. Usually. There are periods on 0 CPU usage but during the incident each Opus session was never at 0 CPU.
You can use the steps described in the FAQ (particularly those to do with tracking down memory leaks) to see if there are any third party components that might be involved.
Opus doesn't do anything special to detect file changes on network drives, they come through the same change notification system that local drives use.
We seem to be seeing this problem in the absence of the broadcast issue. It's happening to us right now. Opus 10.1.0.0 x64 is currently not detecting file changes (local or network) on Windows Server 2008 R2. It's also slow to open Excel 2010 when an Excel file is double-clicked. It opens Excel immediately when an Excel toolbar button is clicked, though. Other types of files don't seem to be affected.
I have used the debug tool and I can see that one user is creating TONS of file change notifications due to a statistical simulation job he's running. If I watch the folder that user is writing to Opus does show the file changes happening without having to hit F5 to see them.
Does it make sense that Opus might struggle to keep with with displaying file changes to other users if one user is generating a constant stream of file changes?
If you have the folder tree open Opus has to process all file notifications in the system. We are hoping to improve the performance of this in the next beta, but in the mean time if you close the folder tree it should improve things as then Opus only has to monitor the current folder.
Thanks for the help getting to the bottom of this. Opus returned to normal after I terminated the user process that was generating the stream of file changes and then closed and re-opened Opus. In case it helps at all, another thing I noticed is that while this was going on each Opus session on the computer was consuming a steadily increasing amount of RAM. By the time I killed the offending process each Opus instance was using more than 250 MB of ram which is ~5x the normal amount.
I take it from your comment that 10.2 doesn't have any changes in it relative to this feature but the next version may.
I now believe that the IP broadcast events were purely coincidental. Unfortunately, now the topic inaccurately describes the issue which seems to be an inability of Opus 10 to keep up with what I guess you could call a file change storm. For other's reading this: this is what I believe is the state of Opus 10: if one or more users generate a flood of file changes and other users have the folder tree open those users may experience a significant delay regarding file change detection for both network and local drives.