• jenkins-2.223

      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).

          [JENKINS-19828] Kill or rework auto refresh

          Oleg Nenashev added a comment - - edited

          > Isn't "1" why we're discussing Servlet 3 to get SSE?

          I suppose this is a question to Jesse. Could you give a link to this discussion?

          Additional approach:
          4. Alter the default behavior in layout.jelly (disable autorefresh if norefresh is unspecified)

          Oleg Nenashev added a comment - - edited > Isn't "1" why we're discussing Servlet 3 to get SSE? I suppose this is a question to Jesse. Could you give a link to this discussion? Additional approach: 4. Alter the default behavior in layout.jelly (disable autorefresh if norefresh is unspecified)

          Daniel Beck added a comment -

          http://jenkins-ci.org/content/thinking-about-moving-servlet-30 says (with many inline links):

          Jenkins devs are thinking about ways to update page contents post load, for example so that the list view will keep updating as stuff happens. WebSocket was discussed as an option, and then server-side events, which seems to be the current favorite.

          Daniel Beck added a comment - http://jenkins-ci.org/content/thinking-about-moving-servlet-30 says (with many inline links): Jenkins devs are thinking about ways to update page contents post load, for example so that the list view will keep updating as stuff happens. WebSocket was discussed as an option, and then server-side events, which seems to be the current favorite.

          Jesse Glick added a comment -

          Yeah I would really advocate the first option.

          Jesse Glick added a comment - Yeah I would really advocate the first option.

          Daniel Beck added a comment -

          Config AutoRefresh Plugin is on its own, as documented on https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties

          No compatibility guarantee
          In general, these switches are often experimental in nature, and subject to change without notice. If you find some of those useful, please file a ticket to promote it to the official feature.

          Daniel Beck added a comment - Config AutoRefresh Plugin is on its own, as documented on https://wiki.jenkins-ci.org/display/JENKINS/Features+controlled+by+system+properties No compatibility guarantee In general, these switches are often experimental in nature, and subject to change without notice. If you find some of those useful, please file a ticket to promote it to the official feature.

          Daniel Beck added a comment -

          Not sure which to resolve as Duplicate here. While the other is older, this one has more (bad) options.

          Daniel Beck added a comment - Not sure which to resolve as Duplicate here. While the other is older, this one has more (bad) options.

          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

          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

          Jesse Glick added a comment -

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

          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?

          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?

          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.

          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.

          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.

          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.

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

              Created:
              Updated:
              Resolved: