Submit Feedback
Legacy Knowledge Base
Published Sep. 10, 2025

Performance issues while automatically propagating default fragments changes during deploy process

Written By

Madhusudan Sharma

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

  • Facing slowness issues when trying to add/edit a content page (other types of pages work fine). The slowness is observed when starting the portal and trying to add/edit the content page. After clicking on the edit button, the page keeps loading for around 30 minutes and a white screen appears for the time being.

Environment

  • Liferay DXP 7.4

Resolution

  • To resolve the slowness behavior, please navigate to the Application Menu → Control Panel → Instance Settings → Page Fragments (under Content and Data) → again Page Fragments → uncheck the 'Propagate Default Fragments Changes During Deploy Process Automatically' option and restart the server.

Additional Information

  • There is a procedure during startup to update all the fragment entry links by fetching all the fragment entry links belonging to a given fragment entry into memory and then iterating over them and running the update logic on each one.
  • However, the logic doesn't scale well for large portal instances with many detailed content pages, since it fetches every fragment link into memory at once.
  • The option 'Propagate Default Fragments Changes During Deploy Process Automatically' allows an admin to enable/disable the propagation of changes for the Default Fragment on the startup. This option is active by default.
  • When the option is disabled (unchecked), default fragments will not be propagated when the portal is restarted.
  • Additionally, after disabling this option, a new 'Propagate Changes' button will appear that will allow to manually propagate the default fragments. This might help you to overcome the performance issues.
  • This new button will trigger the propagation of all default Fragments in all sites (just like when you re-start). This process runs in async, users can move out of this setting screen and the process will not stop.
  • The propagation of changes to the default fragment always happens in the deployment process by definition, it has always been established this way.
  • There are some scenarios, where performance issues can be experienced (in specific cases), so for this, we have enabled the option to do the propagation after the deployment (i.e. manually using the 'Propagate Changes' button) to avoid performance issues.
  • Related Article: OutOfMemoryError on startup when there are a lot of very large FragmentEntryLinks
Did this article resolve your issue ?
Legacy Knowledge Base
Did this article resolve your issue ?