Technical FAQs

Ask a Question

StruxureWare DCE “Unable to retrieve data from server. Attempting to connect…” message received

Issue:
 
StruxureWare Data Center Expert (DCE) may display the following error message via the thin client (web interface): Unable to retrieve data from server. Attempting to connect…

This message may be displayed for a brief period of time or be persistent due to a problem. Depending on the root cause, the DCE thick client installed on a PC may not successfully log in to the server.



Product Line
  • StruxureWare Data Center Expert 7.X
 
Environment
  • StruxureWare Data Center Expert 7.X
  • Users receiving error message while performing software upgrades
  • Users receiving error message during normal server operation
 
Cause
 
This message is displayed when the Java process is not yet fully responsive, meaning ready to serve requests. It is normal to see this message for a short period of time during DCE upgrades. Usually the upgrade process continues and the message disappears but if the message is displayed for an extended period of time, typically there is a problem with the Java process starting.
 

Resolution

Read below for the possible causes with information on how to diagnose and resolve.

 
1. Message displayed during a DCE software upgrade
Please note, it is normal to see this message during the software upgrade process. While the exact amount of time it is displayed depends on the particular server and its configuration, it should not persist for a long while. For reference, with a heavily loaded server, monitoring potentially thousands of devices, it is expected this message will persist for no longer than about 30 minutes.
  • If the message is displayed for a long time, it is recommended to navigate to “http(s)://<server IP or hostname>/capturelogs”, create a server log archive and look in the nbc.xml java server log file for the cause. The log may confirm if the java process is still starting up and the user should continue to wait, as to not disrupt the running upgrade process. Otherwise, it is likely there will be a specific Java exception shown indicating why the process cannot start, which you and your local technical support team can review.  (Note: The capturelogs URL will work without the Java process running properly.)
 
  • Alternatively, if you have SSH access to the server, you can SSH into the server, and look at the /data/logs/nbc/nbc.xml file directly. Please note this requires that the SSH service was enabled by a user prior to the problem. This is NOT enabled by default in DCE’s configuration. This also requires server root access, only available to Schneider Electric technical support.
 
  • It is also possible that the DCE server (physical or VM appliance) may have insufficient storage resources to process and complete the software upgrade. This would also likely cause unhandled Java exceptions shown in the log. Additional resources can be added to a VM appliance by the user, if needed. In addition to following the above methods to retrieve the logs, you can check the upgrade logs for exceptions for this cause. These can be found in /data/logs/upgrade.log and /data/logs/migrate.log.gz in the capture logs archive or on the server.
 
2. Message displayed during normal operation (i.e. user did not attempt to perform a software upgrade)
  • The cause is no different than when the message persists during a software upgrade – the DCE server’s java process is not fully responsive. The above recommendations are still suggested to obtain the capture logs archive and information about what is causing the java process to be unresponsive as a first step.
     

  • Some users may see success with rebooting/power cycling their DCE appliances (physical or VM) but this is not recommended as a first step, rather as a last resort. It may be required if nothing else is possible or recommended by technical support but there is a possibility of data loss depending on the root cause and particular server. It is recommended to contact support, if possible, before trying to avoid further problems. Proceed at your own risk and with caution.

    • If a reboot recovers the server and it begins working normally (no error message is displayed, thick client allows users to log in), it is highly recommended to then try and retrieve the logs to understand what happened to make sure it is not part of a larger problem as to prevent it from re-occurring. Make sure to understand the server configuration details including assigned resources (if a VM), how many devices are being monitored, available storage, and overall system status. Technical support should be able to assist with this and the majority of the information is present within the capture logs archive.
Was this helpful?
What can we do to improve the information ?