java.rmi.NoSuchObjectException: no such object in table error when DocuShare is installed on a Virtual Machine

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‎-‎25T17:06:42.698000000Z from ‎2013‎-‎11‎-‎25T16: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‎-‎26T13:23:49.148000000Z from ‎2013‎-‎11‎-‎26T12: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‎-‎08‎-‎25T08:17:47.749000000Z from ‎2016‎-‎08‎-‎25T08: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‎-‎23T11:24:38.117000000Z from ‎2016‎-‎08‎-‎23T11: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‎-‎23T11:24:38.113842000Z from ‎2016‎-‎08‎-‎23T11: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‎-‎25T06:04:49.274000000Z from ‎2016‎-‎08‎-‎25T06: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.

1.       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 \logs\Monitor.log and\or IndexServer.stdOut file might have time jump if the date and\or time is not synchronized.

Note: You may want to refer to the VMWare KB article 1003736 titled Verifying time synchronization across an ESX/ESXi host environment. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003736

Note: The link above may change from time to time.  For accurate information, please search the internet for “Time synchronization across ESX Host Environment”.

You may also need to check the following:

1.       Collect system information to determine if server (or VM Host) has enough resources.

2.       Determine if any maintenance activities might be conflicting with DocuShare.

3.       Use standard network and hardware troubleshooting to determine there are no problems related to Network Communication.

4.       Run the following command from the root of the drive and again from \jdk1.6.0\bin to ensure its using the JDK\Java version that is bundled with DocuShare.

C:\ >java -version

\jdk1.6.0\bin >java –version

Solution Updated: November 2,2018

Solution ID:  1287

Keywords:        object

Table

Vm

Vmware

Indexserver

Time jump