Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-40080

All pages make multiple /classes requests

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Fixed
    • Icon: Minor Minor
    • blueocean-plugin
    • None
    • tethys

      Not sure why are making multiple calls to {{classes} but this needs to be fixed.

      I've attached a HAR.

        1. blueocean 2016-11-29 10-33-39.png
          blueocean 2016-11-29 10-33-39.png
          120 kB
        2. multiple-classes.har
          7.85 MB

          [JENKINS-40080] All pages make multiple /classes requests

          James Dumay added a comment -

          tfennelly classes could be different across reboots of a Jenkins server so are not cacheable on the client without a cache invalidation scheme. The problem with classes as designed is that we need to make these requests at all which is why I want to take this back to Vivek.

          James Dumay added a comment - tfennelly classes could be different across reboots of a Jenkins server so are not cacheable on the client without a cache invalidation scheme. The problem with classes as designed is that we need to make these requests at all which is why I want to take this back to Vivek.

          Michael Neale added a comment - - edited

          Cache invalidation is a non issue as the web app is reloaded on server restart in all cases anyway

          Michael Neale added a comment - - edited Cache invalidation is a non issue as the web app is reloaded on server restart in all cases anyway

          James Dumay added a comment -

          michaelneale a client side cache has no notion of the server being restarted.

          James Dumay added a comment - michaelneale a client side cache has no notion of the server being restarted.

          Michael Neale added a comment -

          ah, in that case.. carry on. I was thinking something scoped to document or window as a "Cache" which would be blown away.

          Michael Neale added a comment - ah, in that case.. carry on. I was thinking something scoped to document or window as a "Cache" which would be blown away.

          Tom FENNELLY added a comment - - edited

          jamesdumay michaelneale should be very easy for us to invalidate this kind of cache as the BO client-side UI gets a list of the active plugins (and their versions) + the version of the installed Jenkins on every page load. It can easily check this and invalidate if anything changes or is added.

          Tom FENNELLY added a comment - - edited jamesdumay michaelneale should be very easy for us to invalidate this kind of cache as the BO client-side UI gets a list of the active plugins (and their versions) + the version of the installed Jenkins on every page load. It can easily check this and invalidate if anything changes or is added.

          Tom FENNELLY added a comment -

          FYI, see JENKINS-40768 as something that can help make this happen.

          Tom FENNELLY added a comment - FYI, see JENKINS-40768 as something that can help make this happen.

          Tom FENNELLY added a comment -

          Seems strange that this JIRA has been pushed out completely and marked as "minor", while the likes of JENKINS-40487 is in and is marked "major". Both of them are essentially the same problem i.e. reducing the number of backend calls that the client-side needs to make.

          I have a tentative fix for this using localStorage, the basis of which I think can be a very useful piece of infra to help us with per domain caching of other things e.g. localization data, maybe CSS, client-side logging levels if we get to doing that right etc etc. In this specific case, it results in the calls for classes to be completely eliminated once the client has loaded and cached that info, with the cache being wiped/invalidated if there's a new Jenkins instance on the backend, or if the plugins change (installs, updates, removals).

          Tom FENNELLY added a comment - Seems strange that this JIRA has been pushed out completely and marked as "minor", while the likes of JENKINS-40487 is in and is marked "major". Both of them are essentially the same problem i.e. reducing the number of backend calls that the client-side needs to make. I have a tentative fix for this using localStorage, the basis of which I think can be a very useful piece of infra to help us with per domain caching of other things e.g. localization data, maybe CSS, client-side logging levels if we get to doing that right etc etc. In this specific case, it results in the calls for classes to be completely eliminated once the client has loaded and cached that info, with the cache being wiped/invalidated if there's a new Jenkins instance on the backend, or if the plugins change (installs, updates, removals).

          Tom FENNELLY added a comment -

          I pushed the changes I made to https://github.com/jenkinsci/blueocean-plugin/pull/683

          Will stop progress on this now.

          Tom FENNELLY added a comment - I pushed the changes I made to https://github.com/jenkinsci/blueocean-plugin/pull/683 Will stop progress on this now.

          Michael Neale added a comment - - edited

          I have moved this into review in the sprint, as it looks pretty well done, and in review. Is this related to: https://issues.jenkins-ci.org/browse/JENKINS-39747 possibly?

          Michael Neale added a comment - - edited I have moved this into review in the sprint, as it looks pretty well done, and in review. Is this related to: https://issues.jenkins-ci.org/browse/JENKINS-39747 possibly?

          Tom FENNELLY added a comment -

          No, I don't see how this could be related to JENKINS-39747.

          Tom FENNELLY added a comment - No, I don't see how this could be related to JENKINS-39747 .

            tfennelly Tom FENNELLY
            jamesdumay James Dumay
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: