Java & Tomcat Update (JRE 17, Tomcat 10)
Background
Due to security, stability and performance reasons, it's highly recommended to run XPLG with an updated Java and Tomcat versions. During product releases we include minor updates to these components, and occasionally, when migrating to a major version version we release a dedicated patch to perform a full migration.
The deployment of the update is simple and is done as any other patch that is published on XPLG. In addition, XPLG saves a complete backup for roll back purposes.
Checking the Java version
Check the current Java version your deployment is using:
Go to PortX > System > System Health.
Select the 'System Information' section and look for 'Java Version'.
In case the displayed Java version is lower than the one in the subject of this page, its recommended that you'll deploy the update.
Note: if you're running XPLG as a cluster with multiple instances, make sure to check each one (under the same section in the System Health console).
Upgrade Prerequisites
Make sure that on each machine that runs XPLG, you have at least 3GB of available local disk space.
Ensure you have a valid V7 license. Go to PORTX > Settings > License to verify. Contact us for additional information.
Linux: In case you are running XPLG as a service, it is mandatory to follow these steps:
Stop XPLG services (on each machine)
Run each XPLG process from its installation directory manually (cd INSTALL_DIR → sh runXpoLog.sh start)
At the end of the update/validation, stop each XPLG process from its installation directory manually (cd INSTALL_DIR → sh runXpoLog.sh stop)
Run XPLG services (on each server)
Load Balancer usage: In case you are using a load balancer in-front of XPLG servers, it is recommended to deploy the update by a direct browsing to one of the XPLG nodes (it has no impact which cluster node), and then publish the patch to the cluster.
Updating the Java version
Apply the patch to update the internal Java version:
Download the suitable patch for your installation Windows or Linux (all deployments are 64 bit OS). Do not extract the downloaded zip file.
Go to PortX > System > About - and publish patch on all nodes (select all nodes if you’re running multiple instances in a cluster).
Once done, verify the following:
Go to PortX > System > About once again and validate you see the patch 9001 listed.
Go to PortX > System > System Health ('System Information' section) and look for 'Java Version' - you should see version 17 listed.
Note: if you're running XPLG as a cluster with multiple instances, make sure to check each one (under the same section in the System Health console).
After verification
XPLG keeps a full backup for a rollback, if required. We recommend running XPLG for a few days to verify everything is well before removing the backup.
Once verified at PortX > System > System Health ('System Information' section) that each of the instances uses the updated Java version:Go to INSTALLATION_DIRECTORY (of each XPLG instance you're running).
You should see a ‘jre’ directory which is the latest one and contains JAVA 17. If you see any other directories that start with jre remove them (there should be a single ‘jre’ directory under the installation directory of each instance.
Remove the directory java8_backup.
Roll Back
During the update, XPLG keeps a full backup for a rollback, if required. To perform a rollback follow these:
Stop all XPLG services
On each installation, delete the following directories and files from the root installation directory (INSTALL_DIR):
ant
collection
conf
defaultroot
jre
knowledge
lib
plugins
ServletContainer
XpoLog.lax / XpoLog.sh.lax
Copy everything from INSTALL_DIR/java8_backup/patch_TIMESTAMP/ to the INSTALL_DIR
Start XPLG service
Repeat on each XPLG installation separately
Once done, verify the following:
Go to PortX > System > About once again and validate you do not see patch 9001 listed.
Go to PortX > System > System Health ('System Information' section) and look for 'Java Version' - you should see version 8 listed
Note: if you're running XPLG as a cluster with multiple instances, make sure to check each one (under the same section in the System Health console)