Attempting to upgrade an I/A Series R2 Enterprise Server station and the database conversion fails: java.lang.OutOfMemoryError
I/A Enterprise Server R2 (all versions)
The issue is related to the limitation of the Java Virtual Machine (JVM). The conversion process is attempting to perform the upgrade on the station database and is exceeding the 1GB Java heap during the process. This typically occurs on an Enterprise Server station where the station database (db) contains a large number of log objects and associated logged data records. Even though the records are archived in the SQL, the running station (log objects) still maintains records within each object.
Verify that the Java heap is configured to allocate the maximum memory. Use the Windows Explorer and locate the nre.properties file (\niagara\lib directory). Edit with a text editor and verify the setting is Java.options=-Xmx1024MB. If not, change and save then restart the Niagara service and try to upgrade again.
If the upgrade or conversion still fails (out of memory error), logs will need to be cleared in the running station to decrease the number of logged records.
Restart the station in the current version (prior to the upgrade).
Open the station and save the current records to the associated SQL database. Select the Log Service (double click) and perform an archiveAll command (WorkPlace Pro menu items - Command). The archiveAll command causes the data currently held in every log object to be immediately archived (sent to the LogService archive destination). Note this applies even to logs that are not configured to archive (daily and/or near full).
There are two methods of clearing the logs. The first method involves selecting each log object (double click) and perform a clear command (WorkPlace Pro menu items - Command). The clear command clears all log data currently held in the object’s log buffer.
The second method utilizes the AdminTool object to globally modify the log buffer sizes to temporarily decrease the buffers that will subsequently remove records that currently exist in the log object. The AdminTool object is a special “utility” apps object, available in the Local Library (tridium/apps/AdminTool). This object provides an admin-level command to “Search and Replace” property values for objects in the station database. Config properties define the property name to search, new value to write, plus other parameters for filtering and recursion. This operation automates what would otherwise be a manual process of opening and modifying multiple objects’ property sheets.
Note: The adminTool will globally apply the changes to objects defined within the utility. Multiple iterations of this process may be required if log objects are configured with different buffer sizes.
Open the local library and copy the AdminTool object to the station's root directory.
Open the AdminTool properties and select the Config tab.
rootNode -- Configure the swid of the starting point (upper hierarchy) of the station database in which the AdminTool function operates. This can range from the station’s root (/db/stationName) to any container or primitive object in the station’s database. If the recurseChildren property is True, the AdminTool function applies to any and all objects under the rootNode swid. In Tree View, a right-click “copy” on any object under the station captures its swid. Use CTRL-V to paste the swid into the rootNode field of the property sheet.
propertyName -- The target property name, exactly as shown on the object(s) property sheet(s). The property should be a read-write type. In this example, configure the propertyName to bufferSize.
elementName -- Not required for most properties that specify a single value of type float, integer, boolean, or string. In this example, leave unchanged "-".
newValue -- The new value assigned to all matching properties in (and under) the specified rootNode. In this example, configure the newValue to 1 (bufferSize temporarily changed to size of 1).
recurseChildren -- Defines if the search-and-replace function is extended to all children (and subchildren, etc.) of the specified rootNode. In this example, configure the recurseChildren to True.
objectTypeFilter -- Defines a match filter, meaning only objects of this matching type are affected. The asterisk (*) is used as a “wildcard.” Partial strings of object types are supported, for example, AnalogO* will apply to object types AnalogOutput and AnalogOverride. In this example, configure the objectTypeFilter to *Log (modify all logs e.g. AnalogLog, BinaryLog, IntegerLog, MultistateLog, and StringLog). Note: The entire log type could be specified to only apply the changes to a specific type.
nodeNameFilter -- Defines a match filter, meaning only objects with matching name are affected. The asterisk (*) is used as a “wildcard.” In this example, leave unchanged "wildcard."
propertyValueFilter -- Defines a match filter, meaning only objects with this exact value are affected. In this example, leave unchanged "wildcard."
Execute the search and replace command (WorkPlace Pro menu items - Command).
Return the newValue to the required buffer size and execute the search and replace command. The smaller database can now be saved and upgraded or converted as required.