Note: This solution applies to DocuShare 6.5.x or higher.
Issue
Example of time jump from the {dshome}\logs\Monitor.log file:
Where {dshome} is replaced with the installation path for DocuShare. The default installation path is C:\Xerox\Docushare. Depending on your installation environment the path may vary.
13 Feb 2013 15:30:47 [main] INFO - MonitorServerImpl.startupSystem: primary montor - not in sequence mode
13 Feb 2013 15:30:47 [main] INFO - MonitorServerImpl.startServers: booting service [0] rmiserver<><></></>
12 Feb 2013 23:10:00 [Thread-12] INFO - MonitorServerImpl$ServiceStreamReader.run: start for rmiserver
12 Feb 2013 23:10:00 [Thread-10] INFO - MonitorServerImpl$ServiceStreamReader.run: start for rmiserver
Example of time jump from the {dshome}\logs\IndexServer.stdOut file:
23 Jan 2013 13:01:56 - [Thread[Thread-45,5,main]] - DSServerImpl.onClassStringsChanged called
23 Jan 2013 13:02:05 - [Thread[Thread-45,5,main]] - DSServerImpl.onClassStringsChanged called
23 Jan 2013 12:48:32 - [Thread[Thread-45,5,main]] - DSServerImpl.onConfigChanged called with license
23 Jan 2013 12:48:32 - [Thread[Thread-45,5,main]] - Dumping the cached license
The error is recorded in the {dshome}\logs\IndexServer.log.
25 Jan 2013 11:19:26 [Thread-22] ERROR - receive error: java.rmi.NoSuchObjectException: no such object in table; nested exception is: java.rmi.NoSuchObjectException: no such object in table
25 Jan 2013 11:19:26 [Thread-22] ERROR - JobQMgr.run: Error checking block queue: com.xerox.docushare.DSException: receive error: java.rmi.NoSuchObjectException: no such object in table; nested exception is: java.rmi.NoSuchObjectException: no such object in table
The following error may be displayed in the Windows Server System Log:
Information 26/11/2013 4:06:42 AM Microsoft-Windows-Kernel-General 1 None "The system time has changed to 2013-11-25 T17:06:42.698000000Z from 2013-11-25 T16:47:31.064676500Z.
Information 27/11/2013 12:23:49 AM Microsoft-Windows-Kernel-General 1 None "The system time has changed to 2013-11-26 T13:23:49.148000000Z from 2013-11-26 T12:52:17.020456700Z.
The following error may be displayed in the Windows Server Event Log:
Information 8/25/2016 4:17:47 AM Microsoft-Windows-Kernel-General 1 None The system time has changed to 2016-0-25 T08:17:47.749000000Z from 2016-08-25 T08:17:47.750691700Z.
Information 8/23/2016 7:24:38 AM Microsoft-Windows-Kernel-General 1 None The system time has changed to 2016-08-23 T11:24:38.117000000Z from 2016-08-23 T11:24:38.117832400Z.
Information 8/23/2016 7:24:38 AM Microsoft-Windows-Kernel-General 1 None The system time has changed to 2016-08-23 T11:24:38.113842000Z from 2016-08-23 T11:31:29.522000000Z.
Warning 8/23/2016 7:14:09 AM Microsoft-Windows-Time-Service 50 None The time service detected a time difference of greater than 5000 milliseconds for 900 seconds. The time difference might be caused by synchronization with low-accuracy time sources or by suboptimal network conditions. The time service is no longer synchronized and cannot provide the time to other clients or update the system clock. When a valid time stamp is received from a time service provider, the time service will correct itself.
Information 8/25/2016 3:04:49 AM Microsoft-Windows-Kernel-General 1 None The system time has changed to 2016-08-25 T06:04:49.274000000Z from 2016-08-25 T06:04:49.275402200Z.
Warning 8/25/2016 3:04:49 AM Microsoft-Windows-Time-Service 52 None The time service has set the time with offset 14636935015628845 seconds.
Reason / Possible Cause
This issue is most commonly caused by:
· VMWare time jumping is jumping by more than 5 minutes because of time sync between VM Host and Guest.
· Long running VM Snapshots that take more than 5 minutes.
Other possible causes include:
· Time changes to any Operating System can cause the error.
· Software conflicts such as backup or any other maintenance activities scheduled.
· Issues with the NIC card or Network issues can cause the error.
· Resource Starvation.
· JDK\Java version conflicts or older\newer version of JDK\Java installed.
This issue typically happens when DocuShare is installed on a VMWare environment however, in rare circumstances it may happen when DocuShare is installed on physical server. DocuShare uses RMI Communication and this error is saying that the RMI communication held in the JVM memory stack has been lost so when it's called for its not found in the table. This typically happens during garbage collection when memory runs low to release resources or there was some external communication failure. Most applications such as Guest OS server, Exchange Servers, DNS, LDAP Servers, etc... may not experience any issues since they do not use RMI Communication (ie. Java RMI Garbage Collection).
Note: For more information on Java RMI Garbage Collection, please search the internet for Java RMI Garbage Collection.
Solution
Note: Restarting DocuShare will only temporarily resolve the issue. To fix the issue you must follow the steps below to determine what is causing the issue to happen.
Verify that the date and\or time is synchronized across the ESX Host environment. If one of the VM Guest is a Domain Controller, verify that the Domain Controller date and\or time is also synchronized with the VM Host. The VM Guest where DocuShare is installed should also be synchronized with the Domain Controller or VM Host. The {dshome}\logs\Monitor.log and\or IndexServer.stdOut file might have time jump if the date and\or time is not synchronized.