Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-105078

A race condition can be triggered when deploying large portlets, causing the portlet context and config to be incorrect



      It's possible to cause a race condition when starting a bundle while attempting to view the portlet at the same time.

      This issue can be easily reproduced following the steps on LPP-35599 (I will not link any portlets used as they are client-specific).

      The problem stems from the PortletConfigFactoryImpl and PortletContextFactoryImpl classes, specifically in the create methods.  When starting a bundle, we add an entry to each factory for the root portlet.  This entry is valid.

      However, when we render the portlet, we add in a scoped entry as well.  This entry is fine if we've allowed the portlet to complete it's deployment.  However, if we attempt to render the portlet between the time the root portlet is added to the factories and when the portlet has completed it's deployment, we use the undeployed versions of the context/config, which is missing much information.  The solution is to check the portlet we are attempting to create context/configs for with the existing context/config and remove the old entry should it be stale.

      Steps to reproduce:

      1. Deploy a very large custom portlet (can be found on LPP-35599)
      2. Once the portlet has completed deployment, add it to a page
      3. Verify the portlet loads correctly
      4. Using gogo shell, stop the bundle of the portlet and start is back up
      5. Immediately after the bundle begins starting back up, refresh the page with the portlet on it.
      6. Continue to do so until the portlet is finished deploying

      Expected Results: Portlet is loaded correctly

      Actual Results: Portlet is using an incorrect title and another contextual information


      Reproduced on:

      Master: No, however the this is because I do not have a sample portlet to test with.  The code to be changed is the same between master and 71x, so I assume this issue is reproducible.

      72x: No, see above

      71x: Yes 2c49a080a6437cf6670e07b25e0ad115d12d9351




            summer.zhang Summer Zhang
            christopher.kian Christopher Kian
            Kiyoshi Lee Kiyoshi Lee
            0 Vote for this issue
            0 Start watching this issue


              2 years, 42 weeks, 6 days ago


                Version Package
                7.1.10 DXP FP17
                7.2.10 DXP FP4
                7.3.0 CE GA1
                7.3.10 DXP GA1