The modified date/time stamp seen for databases is creeping forward more and more into the future. This can be seen in the database properties.
Internal to Domino there is a need to have a unique date/time stamp. This allows all of the processes to recognize when something has changed. Domino date/time stamps are 1/100th of a second or 10ms. If the function OSCurrentTIMEDATEUnique() function is called more than once within a 10ms period the date/time returned one would think would be the same but this function must return a unique date/time stamp so it then has to jump ahead to the next 10ms period even though we are not there yet. A 10ms period to us may see very small and fast but to a computer it is not. Many instructions can occur within a 10ms period and computers are only getting faster.
When using a product like SMSDOM we have to mark the messages dead in order to prevent Domino from routing the messages before we scan them. When we are done scanning a message we will then remove the routing state of dead so that the router can then deliver the message. This is the updates we are doing for real time scanning. The faster the machine, the more mail to process within a second can cause the time to creep forward seconds, minutes, or even days into the future. SMSDOM is working normally and so is Domino behavior being they require the unique date.
1. In the future maybe IBM can add a additional stamp like a counter for example that goes with the date/time stamp. For example one process completes and when OSCurrentTIMEDATEUnique() function is called it returns 12/12/2011 10:23:01:01, another change occurs within the same 10ms period so the when the OSCurrentTIMEDATEUnique() function is called it also receives the same date/time stamp of 12/12/2011 10:23:01:01 so it then increments a counter to 2 meaning this is the second change within that 10ms period. A change like this can be a huge undertaking though because so many processes depend on the way it works now and each of these would also have to be changed. Also, there could be many other ways to achieve the same thing and so they may choose a different approach. However, if a customer is concerned about this creeping forward of the modified date/time stamp then just put in an enhancement request to IBM and just let them figure out how they want to fix this in the future.
2. Check the number of threads SMSDOM is using. There are multiple ways of doing this. The easiest way is to use the Domino Administrator client and connect to server using SMSDOM. Select the Server tab, select the Status sub tab, and then Server Tasks. This will show all the task. If there are too many write or mail threads associated with SMSDOM use the SAVWriteThreads and SAVMailThreads notes.ini parameters to tweak these back. There should really be no need to go above 16 threads for each. To make these changes using the Domino Administrator client select Server Console on the left side below Server Tasks, click the Live button at top right, and then type the following two commands at the Domino Command line at the bottom and press send after each:
set config SAVWriteThreads=16
set config SAVMailThreads=16
***Note - After adding/modifying the SAVWriteThreads or SAVMailThreads parameters it requires a restarting SMSDOM to take affect.
A workaround could be the throttle back the amount of load on the server because the more there is to process within a 10ms period the more the date/time will creep forward. So you could move load to other servers. This may be undesirable because usually more money is pumped into newer faster machines to handle more load and this method is trying to slow these servers down.
Another way could be to put a slower NIC card in the server which will slow down all traffic to and from the Domino server.
Lastly, even though the modified date is creeping forward this is okay and will not cause other problems within Domino or SMSDOM. If you are okay to ignore this with an understanding that this is not related to some abnormal condition and just by design then this is okay also.
Imported Document ID: TECH177024
Subscribing will provide email updates when this Article is updated. Login is required.