Liferay Support Services seeks to resolve unintended functionality, otherwise known as product defects, via patching or configuration changes to Liferay Digital Experience Platform, Liferay Portal EE, and Liferay Commerce ("the product"). Reported issues must be reproduced by Support Services in an uncustomized product instance. Some reported issues (e.g., API issues) can be verified and reproduced with a specific reporting mechanism.
For detailed policies please review the following sections:
Emergency fixes for Liferay Commerce will be made available on the latest micro version of a customer's minor version. Customers may be required to upgrade to the latest minor version available in order to receive a maintenance release.
Any behaviors or issues that conflict with the product's intended functionality will be verified and resolved via patching or configuration changes to the product. The official documentation for the product determines this functionality.
- Liferay DXP 7.1 Documentation
- Liferay DXP 7.0 Documentation
- Liferay Portal 6.2 EE Documentation
- Liferay Portal 6.1 EE Documentation
- Commerce Admin Guide
If an issue in the product code inhibits your development, then our support engineers will provide assistance in resolving that Liferay product defect. When reporting the issue, please provide clear information on the specific API. This includes its expected and actual results, and a simple application or script that demonstrates the issue (if available).
Liferay will resolve issues according to the intended functionality of the product. You may need to change any custom development that leverages unintended functionality.
If intended functionality is reported as an API issue, Liferay Support will explain the functionality using the existing code of the product, offer supporting documentation or a simple example. With API issues the intended functionality is not only defined in the official Admin Guide but in the javadocs and the JSON webservice listings. Please see the Liferay API Documentation knowledge base article for more information.
Contact your Account Executive or Customer Experience Manager to discuss options for getting assistance with your custom development.
Once reported, issues enter the Diagnostic Workflow. During the Diagnostic Workflow, Liferay Support investigates the issue, attempting to reproduce it and provide a resolution to the customer. Liferay Support must first reproduce any reported issues on an uncustomized product version. Issues that result from product customization are the customer's responsibility. Issues that Liferay Support cannot reproduce will remain in the Diagnostic Workflow, and are resolved on a case-by-case basis. Issues that are beyond Support Services' coverage will remain in the Diagnostic Workflow and be resolved on a case-by-case basis. Your Account Executive or Customer Experience Manager can assist you with issues not included in Support Services.
Liferay will resolve reproducible, unintended defects in uncustomized product versions via patching or configuration changes in accordance with the product service life policy. Patches will change the product's code. Liferay Support will provide documentation for the code changes with the patch. Customers are required to test the patch to ensure it resolves the issue, and report the results to Liferay Support in a timely manner. Prior to installing a patch, customers should backup their system (e.g., code, files, database). To verify that the patch does not conflict with any custom development, customers should install the patch to a non-production environment first. Customers are responsible for any issues with custom development that arise as a result of product defect resolutions.
With a desire to increase uptime and availability many customers implement rolling restarts. Rolling restarts allows customers to have near 100% uptime despite server maintenance by selectively shutting down one JVM instance within a cluster, performing the necessary maintenance on that instance, and then restarting that instance to join the cluster again. This process is repeated until all the nodes in a cluster have been updated.
- Liferay seeks to ensure that Liferay DXP is compatible with the industry accepted practice of rolling restarts to modify portal properties, install and uninstall fix packs, install new plugins or modules, update existing plugins and modules, and update the minor java version given that these functions meet the rolling restart requirements.
- Liferay seeks to ensure that Liferay DXP is compatible with the industry accepted practice of rolling restarts to the extent that the product is minimally functional and able to respond to limited requests during the defined maintenance window. Minimal functionality is defined by Liferay product engineers on a case-by-case basis.
- Liferay recommends mitigating the risks of production updates through the rolling restart technique as opposed to hot deployment. However, the feasibility and implementation of the rolling restart technique within a specific environment would be the responsibility of the customer.
- Liferay Support will offer guidance in determining if a Liferay product update meets the rolling restart requirements.
- Successfully performing the rolling restart technique involves the interoperability of multiple third-party technologies. Configuring the third-party technology necessary to perform a rolling restart within a cluster would be the responsibility of the customer.
Rolling Restart Requirements
Any maintenance function performed while utilizing the rolling restart technique must meet the below requirements to be tested as compatible with Liferay DXP.
Fix Pack Installation
Fix pack installation utilizing a rolling restart technique is assured as compatible with Liferay DXP as long as the new fix pack is revertible and there are no non-revertible fix packs in between the currently installed fix pack and the desired fix pack. Fix packs which are or will be included in a service pack contain non-revertible database changes. These fix packs will be identified as non-revertible on the Customer Portal and have Important Changes documentation with them or have been documented in the Rolling Restart - Breaking Changes knowledge base article.
Typically, non-revertible fix packs end with a zero. All service packs contain non-revertible fix packs.
New Plugins or Modules
The deployment of new plugins or modules utilizing the rolling restart technique is assured as compatible with Liferay DXP as long as the plugins or modules do not delete or rename any columns from the database or modify the data in a way that breaks compatibility with existing versions. Any updates which delete tables or break compatibility should be performed while all nodes in a cluster are shut down.
Updating Plugins or Modules
Updating already deployed plugins or modules utilizing the rolling restart technique is assured as compatible with Liferay DXP as long as the plugins or modules do not delete or rename any columns from the database or modify the data in a way that breaks compatibility with the previous version. Any updates which delete tables or break compatibility should be performed while all nodes in a cluster are shut down.
Development techniques exist (e.g., blue-green deployment) which can accommodate database schema changes while utilizing the rolling restart technique. Liferay products will not utilize these development techniques as the technique requires minor changes over time applied specific order and Liferay can not guarantee that product releases will be applied in the proper order.
Blue-green deployment can take place in custom development without impacting the functionality of Liferay Software. Please consult with an Account Executive or Customer Experience Manager to explore options related development assistance.
Java Version Updates
Updating a Java JDK installation utilizing the rolling restart technique is assured as compatible with Liferay DXP given that the version increment is limited to a minor version. Updating the major version of the Java JDK installation utilized by Liferay DXP is not assured as compatible with the rolling restart technique and should be performed while all nodes in a cluster are shut down.