This could be related to a bad Content Filtering Rule.
If the bad rule was created while SMSDOM was running the issue may not be recognized right away. And by the time it is noticed the server may be unresponsive and require a nsd kill to bring it down. Bringing the server back up with nntask will just immediately begin taking high CPU on startup. You can see this by monitoring nntask.exe in task manager.
If sms debugging is on you may notice on initialization that it appears to stop logging after it says Reading CF rule from note: <some note ID # in decimal>. The Note ID can help us identify the exact document causing the problem.
You recently created a content filtering rule before the issue was noticed where nntask was using high CPU and server became unresponsive. Inside the Rules tab you created a number of expressions. But when the GUI calculated the number expressions during the save it increased the number by one in the COUNT variable. For example, there are only three expressions but the COUNT variable somehow becomes 4. So now when nntask tries to start up or read in the CF rules it is looking for an additional expression that does not exist.
If you are experiencing this condition and you know you just recently created a CF rule that may be causing the problem you can fix this problem a couple ways.
1. You can start Domino without nntask, go into the settings and delete the last CF rule that which was recently created and then nntask should be able to start fine after that.
2. You could also submit your sav.nsf file to our support team where we can check to see if this condition exist and if so fix the rule and then return the file.
This is machine translated content
Login to Subscribe
Please login to set up your subscription.
Didn't find the article you were looking for? Try these resources.