Details

    • Similar Issues:

      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

            Hide
            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

            Show
            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
            Hide
            jglick Jesse Glick added a comment -

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

            Show
            jglick Jesse Glick added a comment - sam sa please take it to the Jenkins users’ list rather than adding noise to the JIRA issue.
            Hide
            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?
            Show
            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?
            Hide
            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.

            Show
            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.
            Hide
            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.

            Show
            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

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

                Dates

                • Created:
                  Updated: