Key Live Collaboration Environment Variables

The configuration checker evaluates key ENOVIA Live Collaboration environment variables that can be easily overlooked. Setting them appropriately for system-wide use can improve performance dramatically. These variables may have been set originally by an ENOVIA engineer, but during upgrades of an application server the variables may be lost because a new application server startup script is used.

Related Topics
System Scaling
Evaluation Details
JVM Options for ENOVIA Live Collaboration Servers

For RIP mode, check the application server's startup script (see the Application Server table) for the environment variables or for a script that gets executed that may set them externally.

A good tip for checking what is being set is to locate the line in the script files that starts the JVM (usually it's near the end and begins with java-install-path/bin/java) and insert a line that pipes the environment to a file.

Example for UNIX/Linux: 
env > env.fil
Example for Windows: 
set > env.fil

Start the application server and edit the env.fil file. Search for the environment variables listed in the ENOVIA Live Collaboration environment variable table.

The MATRIXHOME environment variable should be noted since most traces and scripts are found using this path.

This method should be used if using ENOVIA Live Collaboration Servers. In this mode, ENOVIA Live Collaboration Servers are started using rmireg.sh (Unix) or rmireg.bat (Windows).

A good practice to ensure that the environment variables are set is to create a script or batch file that contains them and call the script directly from the application server startup script or from rmireg.

In Windows, environment variables are checked as follows: the enovia.ini file is checked first; if the variable does not exist then the environment is checked. If still not found, internal defaults are used.

Setting Environment Variables in the Windows Registry

When using the RMI service, environment variables may be also set in the registry. In the Windows Registry Editor a registry key called "Env" can exist under the following key: 

 HKEY_LOCAL_MACHINE\SYSTEM\Services\eMatrix Rmi Service\Parameters

This key can contain ENOVIA Live Collaboration environment variables as registry values. When the RMI service starts it will add these to its environment. These variables can be changed or added directly using regedit or by using the rmiservice with some parameters, for example: 

rmiservice -config "eMatrix RMI Server" -javaoptions "-C-Xss256k"

or 

rmiservice -config "eMatrix RMI Server" -setenv LANG=C -setenv NLS_LANG=American_America.UTF8 -setenv MX_CHARSET=UTF8

Note that "eMatrix Rmi Server" is the default RMI registry key name.

For more information about each ENOVIA Live Collaboration environment variable, see Configuring ENOVIA Live Collaboration and Installing ENOVIA Live Collaboration Server.

Registry Keys to Avoid RMI Gateway-Related Display Problem

When two or more RMI gateways are set, displaying an object can take time. For example, the following scenario illustrates this behavior:

Preparation:

  1. Set three RMI gateways.
  2. Create a new user.
  3. Set a check-in object.

Execute the following steps:

  1. Launch the web client.
  2. Log in as the created user.
  3. Select the Find icon and an arbitrary object.
  4. Select the created object, then Open > View. It takes about 30 seconds to display the object.
  5. Close the displayed window.
  6. Again select the created object, then Open > View. This time, it takes about 23 seconds to display the object.
  7. Close the displayed window.
  8. Again select the created object, then Open > View. This time, it takes only about 1 second to display the object.

If a different user logs into the same client, display of an object occurs immediately.

If the same user logs into a different client, display of an object takes time, as described in the above scenario.

The delay in the display occurs because an automatic update of the root's Windows certificate is tried each time you load a component that verifies a certificate, such as when creating an HTTS connection. This is done only once until the Microsoft DLL is not unloaded. Setting the following registry keys disables this behavior: 

// Key Wow

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\SystemCertificates\AuthRoot]
"DisableRootAutoUpdate"=dword:00000001

// Key x64 or x86 on an x86 computer

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot]
"DisableRootAutoUpdate"=dword:00000001