Legacy Knowledge Base
Published Sep. 10, 2025

Starting nodes concurrently can lead to incorrect module upgrades

Written By

Mariano Alvaro

How To articles are not official guidelines or officially supported documentation. They are community-contributed content and may not always reflect the latest updates to Liferay DXP. We welcome your feedback to improve How To articles!

While we make every effort to ensure this Knowledge Base is accurate, it may not always reflect the most recent updates or official guidelines.We appreciate your understanding and encourage you to reach out with any feedback or concerns.

Legacy Article

You are viewing an article from our legacy "FastTrack" publication program, made available for informational purposes. Articles in this program were published without a requirement for independent editing or verification and are provided"as is" without guarantee.

Before using any information from this article, independently verify its suitability for your situation and project.

Issue

  • Module functionality seems to fail after moving to a newer fixpack.
  • After executing a system:check unsatisfied dependencies like the following appear:
Component with ID 58 is unavailable due to missing required dependencies:
  service dependency [com.liferay.portal.kernel.model.Release (&(release.bundle.symbolic.name=com.liferay.dynamic.data.mapping.service)(&(release.schema.version>=3.2.0)(!(release.schema.version>=4.0.0)))(|(!(release.state=*))(release.state=0)))]

Environment

  • Clustered environment where more that one node is started concurrently.

Resolution

  • If, according to the Release Notes, the new fixpack includes one ore more upgrades, nodes should be started sequentially to avoid race conditions performing upgrades.
  •  If there's no option to start nodes sequentially for versions 7.0, 7.1, 7.2 com.liferay.portal.upgrade.internal.configuration.ReleaseManagerConfiguration.config should be configured in a way that module upgrades don't run by default. For 7.3+ see Auto Upgrade in DXP 7.3 and Above This makes the upgrade executable on demand from the Gogo shell and avoid race conditions, see Upgrading modules using gogo shell
  • If concurrent startup has already been performed and incorrect behavior is perceived, run the system:check command, and search in the Release_ table filtering by servletContextName to check the state of the failing module. Use the following query as an example:
select * from Release_ where servletContextName = 'com.liferay.dynamic.data.mapping.service'
  • Contact Support if state is 1 (failure) providing the retrieved information

 

*

Did this article resolve your issue ?

Legacy Knowledge Base