When applying fix packs or hotfixes, rolling restarts are possible if there are no changes to a specific set of clustering classes or no module schema version changes. The following document is a list of the known fix packs which contain either of these exceptions.
If a breaking change fix pack is encountered when moving from one fix pack to a higher fix pack, then rolling restarts are not possible. A full cluster restart is required. For instance, if fix pack de-28-7010 is currently installed and fix pack de-32-7010 will be installed, then this patching process would require a full cluster restart since de-30-7010 is a breaking change fix pack.
For more information see the Rolling Restart Maintenance policy.
Qualifications for a Breaking Change
There are two types of changes which can make a fix pack ineligible for rolling restart maintenance: scheme version changes and clustering code changes.
Schema Version Changes
The purpose for Liferay-Require-SchemaVersion is to determine if a module upgrade process needs to run.
Essentially, this value is recorded inside of the database in the Release table once all the module upgrades complete. If the value in the database does not match the value in the bnd.bnd, certain things will fail to happen and the service builder services will not be provided to other modules.
At a technical level, when Liferay initializes, the code responsible for injecting service builder services as OSGi components declares that it needs the value specified in bnd.bnd as a dependency (thus the "requires schema version"), while the value in the database is what's actually published. This means that if the two do not match, service builder services will not be made available, thus creating a point of no return.
What this means is that if a Liferay-Require-SchemaVersion is changed in a fix pack and a customer applies the fix pack, they cannot rollback to an earlier fix pack without some components failing to start (because they depended on the service being available) or without restoring a backup of the database which contains the previous schema version.
Important: In DXP 7.1 and in DXP 7.0 starting with fix pack 40 most of the upgrade changes qualify for rolling restart maintenance. New upgrade processes only contain micro data modifications so previous versions of code (starting from fix pack 40) are compatible with these upgrade changes. This means it is possible to perform rolling restarts with fix packs which contain upgrade processes after fix pack 40.
Clustering Code Changes
The purpose of performing rolling restart maintenance is to ensure uptime within a cluster. Thus, rolling restarts are only possible if a node is able to communicate with other nodes in the cluster before and after patch installation. Occasionally, fix packs will contain changes to code which impacts clustering. If one node has a different clustering code-base than other nodes in the cluster, error-free communication with other nodes cannot be ensured.
The types of code changes below are considered a breaking change and when modified by a fix pack make the fix pack ineligible for rolling restart maintenance:
- Changes to clustering code
- Changes to some local service impl classes
- Changes to caching or cache replication code
- Changes to remote services or remote methods
- Additional MethodKeys
DXP Fix Pack Breaking Changes
In order to determine if a fix pack is eligible for rolling restart maintenance please reference the Important Changes and Module Changes sections of the Release Notes tool found in the Resources section of Liferay Help Center. As an additional resource, the below table covers DXP 7.0 fix packs de-01 through de-40.
|Fix Pack||Breaking Change||Release Notes|
|de-08||Schema version and Clustering||Release Notes|
|de-11||Schema version change||Release Notes|
|de-14||Schema version change||Release Notes|
|de-27||Schema version change||Release Notes|
|de-30||Schema version change||Release Notes|
|de-33||Clustering code change||Release Notes|
|de-37||Schema version change||Release Notes|
|de-39||Clustering code change||Release Notes|
|de-40||Schema version change|