My company has recently been having an issue which I can't find any mention of in the forum or documentation. I think I've discovered the cause and fix for it, but I was curious (a) if anyone else has encountered this issue; (b) if this was intentional in the design or if it's more bug-like, and; (c) if an upgrade to Zoom might offer us a better solution.
Beginning some time in March, I found that some of our nightly Zoom scheduled tasks were failing. We have 12 or so tasks, for different websites, and this issue seemed to be happening to a handful of them, but generally not with any consistency or regularity. The problem -- without fail -- was that the .zcfg files were corrupted, and it appeared that happened when the scheduled task started. Trying to run or save the configuration gave the message "No indexing option selected. You have disabled all indexing options. You must select at least one or more indexing options for Zoom to index your website." Since it is impossible to create a file like this through the UI, there had to be some automated process doing it.
At first I thought it might have been the server file synchronization, but this kept happening even after that was turned off. Through assorted testing (and luck) I found that only TWO instances of the Indexer could be running at the same time. If two indexing jobs were already running and I started a third one, it would immediately throw an error in the Application Event Log and write out a bad .zcfg file. Since some of the sites being indexed have somewhat long running jobs (2-3 hours in some cases), this 2-Indexer limit was being hit often, especially after two additional sites were added this spring.
Is this something anyone else has encountered? Can anyone confirm that there is a limit on the number of running Indexer instances? Is this an aspect of the program itself, or can server circumstances bring this about (e.g., limited available memory)? If this situation is unavoidable, is there any way to prevent the error from corrupting the configuration file? (THAT was a very annoying part in this.) We're currently running 7.1.1003 (Pro); would later builds of 7.1 or the new version provide different results -- either by not having an application limit or by maintaining the settings of the configuration?
For the time-being, I've rearranged the schedule of the tasks so that only two jobs would ever be running at one time (outside of extraordinary circumstances). It works, but it's not a perfect solution, as not all the indexing tasks are done before "business hours" kick in for some sites, and there's a great possibility of negative interaction with some other nightly tasks (such as database backups or maintenance).
If anyone has any insights or suggestions, that would be most appreciated.
Beginning some time in March, I found that some of our nightly Zoom scheduled tasks were failing. We have 12 or so tasks, for different websites, and this issue seemed to be happening to a handful of them, but generally not with any consistency or regularity. The problem -- without fail -- was that the .zcfg files were corrupted, and it appeared that happened when the scheduled task started. Trying to run or save the configuration gave the message "No indexing option selected. You have disabled all indexing options. You must select at least one or more indexing options for Zoom to index your website." Since it is impossible to create a file like this through the UI, there had to be some automated process doing it.
At first I thought it might have been the server file synchronization, but this kept happening even after that was turned off. Through assorted testing (and luck) I found that only TWO instances of the Indexer could be running at the same time. If two indexing jobs were already running and I started a third one, it would immediately throw an error in the Application Event Log and write out a bad .zcfg file. Since some of the sites being indexed have somewhat long running jobs (2-3 hours in some cases), this 2-Indexer limit was being hit often, especially after two additional sites were added this spring.
Is this something anyone else has encountered? Can anyone confirm that there is a limit on the number of running Indexer instances? Is this an aspect of the program itself, or can server circumstances bring this about (e.g., limited available memory)? If this situation is unavoidable, is there any way to prevent the error from corrupting the configuration file? (THAT was a very annoying part in this.) We're currently running 7.1.1003 (Pro); would later builds of 7.1 or the new version provide different results -- either by not having an application limit or by maintaining the settings of the configuration?
For the time-being, I've rearranged the schedule of the tasks so that only two jobs would ever be running at one time (outside of extraordinary circumstances). It works, but it's not a perfect solution, as not all the indexing tasks are done before "business hours" kick in for some sites, and there's a great possibility of negative interaction with some other nightly tasks (such as database backups or maintenance).
If anyone has any insights or suggestions, that would be most appreciated.
Comment