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

Kill or rework auto refresh

    XMLWordPrintable

Details

    • jenkins-2.223

    Description

      The auto_refresh query parameter (and associated hudson_auto_refresh cookie) not only wreaks havoc on forms or any other pages that forget to add norefresh=true, it can cause serious performance issues in large Jenkins installations if some team members naïvely turn on auto refresh on the dashboard or some other expensive page and then go home for the night. Options:

      1. Delete this (mis)feature, adding back in more AJAXy behaviors to various pages upon request.
      2. Allow a Jenkins administrator to disable it for a given installation.
      3. Keep it, but make the Refresh time (Functions.configureAutoRefresh) increase exponentially after each automatic refresh, resetting to 10s only after an explicit page load (if these can be somehow distinguished).

      Attachments

        Issue Links

          Activity

            dam321 sam sa added a comment -

            how can we turn off auto refresh ...as we do not have aut refresh enabled but our jenkins instace keeps refreshing every 20 seconds all pages in jenkins does the same.
            version 1.624

            dam321 sam sa added a comment - how can we turn off auto refresh ...as we do not have aut refresh enabled but our jenkins instace keeps refreshing every 20 seconds all pages in jenkins does the same. version 1.624
            jglick Jesse Glick added a comment -

            dam321 please take it to the Jenkins users’ list rather than adding noise to the JIRA issue.

            jglick Jesse Glick added a comment - dam321 please take it to the Jenkins users’ list rather than adding noise to the JIRA issue.

            As a user, it's been years I always disable this. The few times I've used it, it's screwed a form I was filling in and so on.
            So we should indeed either:

            • simply kill it in the main code,
            • or offer a simple way for people to simply disable it totally. Like Oleg says: if the UI has a value of 0 e.g., just do not display the field at all. We could probably even use it as a progressive strategy to kill it: do that, plus define the default to 0 for new installs? And in the meantime, make a poll about that on the users list to take the temperature?
            batmat Baptiste Mathus added a comment - As a user, it's been years I always disable this. The few times I've used it, it's screwed a form I was filling in and so on. So we should indeed either: simply kill it in the main code, or offer a simple way for people to simply disable it totally. Like Oleg says: if the UI has a value of 0 e.g., just do not display the field at all. We could probably even use it as a progressive strategy to kill it: do that, plus define the default to 0 for new installs? And in the meantime, make a poll about that on the users list to take the temperature?
            ssbarnea Sorin Sbarnea added a comment -

            Why was this rejected from 2.0? This "feature" is only creating bugs and should not exist at all. There are other ways to implement refresh whenever this is needed, a generic page refresh is a disaster for so many config pages.

            A web page should never reload itself completely, it does it usually points to bad implementation. I guess the reason why this feature-bug exists is only because it is older than jQuery itself.

            ssbarnea Sorin Sbarnea added a comment - Why was this rejected from 2.0? This "feature" is only creating bugs and should not exist at all. There are other ways to implement refresh whenever this is needed, a generic page refresh is a disaster for so many config pages. A web page should never reload itself completely, it does it usually points to bad implementation. I guess the reason why this feature-bug exists is only because it is older than jQuery itself.
            danielbeck Daniel Beck added a comment -

            Why was this rejected from 2.0?

            2.0 was a specific release 9 months ago and already was behind schedule with the changes that did make it in. This was simply out of scope for that. And given the traction Blue Ocean has I doubt we'll ever develop a replacement in core, the best I expect we'll do is kill it off. However…

            This "feature" is only creating bugs and should not exist at all. There are other ways to implement refresh whenever this is needed, a generic page refresh is a disaster for so many config pages.

            It's opt in. And apparently, the people who do that don't want to go without it, despite all the brokenness.

            danielbeck Daniel Beck added a comment - Why was this rejected from 2.0? 2.0 was a specific release 9 months ago and already was behind schedule with the changes that did make it in. This was simply out of scope for that. And given the traction Blue Ocean has I doubt we'll ever develop a replacement in core, the best I expect we'll do is kill it off. However… This "feature" is only creating bugs and should not exist at all. There are other ways to implement refresh whenever this is needed, a generic page refresh is a disaster for so many config pages. It's opt in. And apparently, the people who do that don't want to go without it, despite all the brokenness.

            People

              Unassigned Unassigned
              jglick Jesse Glick
              Votes:
              15 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: