Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-39298

The entity_picker.js loading is slow for the first response

XMLWordPrintable

      The file entity_picker.js takes 20 seconds+ to load for the first response in a vanilla Confluence. The subsequent response is usually fast after it has been cached. This prevents large instances from loading the file due to a timeout.

      Step To Replicate

      1. Go to > General Configuration > Global Permissions
      2. Click search for the Grant browse permission to field for Groups.

      Observed Result

      The following result takes 20 second to complete even in a newly installed instance.

      This bug affect all the features that require entity_picker.js, for example adding restrictions to Team Calendars or Pages.

      Workaround

      Turning off HTTP compression in > General Configuration > Connection Timeouts may work in some instances.

       

        1. confluence-userpicker.png
          confluence-userpicker.png
          39 kB
        2. image-2016-08-16-16-39-58-530.png
          image-2016-08-16-16-39-58-530.png
          17 kB
        3. sample.png
          sample.png
          39 kB

            [CONFSERVER-39298] The entity_picker.js loading is slow for the first response

            Jiri Hronik added a comment -

            A fix for this issue is available to Server and Data Center customers in Confluence 7.4.10
            Upgrade now or check out the Release Notes to see what other issues are resolved.

            Jiri Hronik added a comment - A fix for this issue is available to Server and Data Center customers in Confluence 7.4.10 Upgrade now or check out the Release Notes to see what other issues are resolved.

            Jason Whitener added a comment -

            I can replicate this on our 6.15.9 version.   See CSP-259186 

            Jason Whitener added a comment - I can replicate this on our 6.15.9 version.   See CSP-259186 

            Tim Eddelbüttel added a comment -

            This week after upgrade the Confluence 5.8 i see this bug in our instance with piwik.js and it is reproducalbe with the group picker dialog.

            Disable HTTP compression on application level should be a workaround. But if you want HTTP compression you can use it on application server level (Tomcat): https://answers.atlassian.com/questions/29951275/tomcat-8---serving-static-content-extremely-slow...

            Is it safe to do this or will there be side effects?

            Tim Eddelbüttel added a comment - This week after upgrade the Confluence 5.8 i see this bug in our instance with piwik.js and it is reproducalbe with the group picker dialog. Disable HTTP compression on application level should be a workaround. But if you want HTTP compression you can use it on application server level (Tomcat): https://answers.atlassian.com/questions/29951275/tomcat-8---serving-static-content-extremely-slow... Is it safe to do this or will there be side effects?

            wu bojie added a comment - - edited

            Hi all,

            I find the solution with my problem.

            Just unclick the "Compress HTTP Responses" in General Configuration -> Connection Timeouts.

            But it still an issue with that setting, hope this will help.

             

            wu bojie added a comment - - edited Hi all, I find the solution with my problem. Just unclick the "Compress HTTP Responses" in General Configuration -> Connection Timeouts. But it still an issue with that setting, hope this will help.  

            Adam Thompson [AVANT] added a comment -

            FWIW, we're seeing the same behaviour across all the applications in the Atlassian stack: serving up any static .js file above a certain size is ridiculously slow and the effect appears to increase with the size of the .js file.  On several very-overprovisioned servers, both Confluence and JIRA are only able to serve up some .js files at ~300kBytes/sec.

            This suggests that it's quite possibly a Tomcat-related problem, or possibly that some processing hook is taking place that's trying to parse the files in memory before handing them out (for security tokens, maybe?).

            Adam Thompson [AVANT] added a comment - FWIW, we're seeing the same behaviour across all the applications in the Atlassian stack: serving up any static .js file above a certain size is ridiculously slow and the effect appears to increase with the size of the .js file.  On several very-overprovisioned servers, both Confluence and JIRA are only able to serve up some .js files at ~300kBytes/sec. This suggests that it's quite possibly a Tomcat-related problem, or possibly that some processing hook is taking place that's trying to parse the files in memory before handing them out (for security tokens, maybe?).

            wu bojie added a comment -

            It also happened for me with 5.10.2.
            (http://<confluence>/includes/js/control.js)

            wu bojie added a comment - It also happened for me with 5.10.2. (http://<confluence>/includes/js/control.js)

            Olivier Bories added a comment -

            Hello,
            I also reproduce this problem in 5.9.7 version.

            Olivier Bories added a comment - Hello, I also reproduce this problem in 5.9.7 version.

            Adam Thompson [AVANT] added a comment -

            I'm also starting to see the same behaviour with the latest versions of Tempo Timesheets installed in recent JIRA builds, and appears to be the same root cause - a single .js file being loaded that takes >2min to transfer to the browser at <100kbps.
            I can't conclusively demonstrate a common link, but both JIRA and Confluence have recently-ish updated some core underlying libraries - I'm now suspecting an upstream bug in one of them somewhere.

            Adam Thompson [AVANT] added a comment - I'm also starting to see the same behaviour with the latest versions of Tempo Timesheets installed in recent JIRA builds, and appears to be the same root cause - a single .js file being loaded that takes >2min to transfer to the browser at <100kbps. I can't conclusively demonstrate a common link, but both JIRA and Confluence have recently-ish updated some core underlying libraries - I'm now suspecting an upstream bug in one of them somewhere.

            Henning Tietgens added a comment -

            For us this is happening with 5.8.10. In Chrome only for the first time, in Firefox for every request (https://<CONFLUENCE>/s/en_GB/5989/aaad9997c145089d7f38b9dea0ac5b91728ef55a.432/_/includes/js/entity_picker.js).

            Henning Tietgens added a comment - For us this is happening with 5.8.10. In Chrome only for the first time, in Firefox for every request (https://<CONFLUENCE>/s/en_GB/5989/aaad9997c145089d7f38b9dea0ac5b91728ef55a.432/_/includes/js/entity_picker.js).

            Adam Thompson [AVANT] added a comment -

            We only see this behaviour on one Confluence instance (don't know why), but I can add two things:
            1. it affects Adaptavist's Enterprise Notification plugin
            2. in the Javascript console, we get this:

            GET https://confluence.ihtsdotools.org/s/en_GB/5993/fdcad23a2bb12e565e0f1d82cc2de4d7ca3297f0.36/_/includes/js/entity_picker.js net::ERR_CONTENT_LENGTH_MISMATCH

            Adam Thompson [AVANT] added a comment - We only see this behaviour on one Confluence instance (don't know why), but I can add two things: 1. it affects Adaptavist's Enterprise Notification plugin 2. in the Javascript console, we get this: GET https://confluence.ihtsdotools.org/s/en_GB/5993/fdcad23a2bb12e565e0f1d82cc2de4d7ca3297f0.36/_/includes/js/entity_picker.js net::ERR_CONTENT_LENGTH_MISMATCH

              dluong Duy Truong Luong
              jcheok Jing Hwa Cheok (Inactive)
              Affected customers:
              27 This affects my team
              Watchers:
              34 Start watching this issue

                Created:
                Updated:
                Resolved: