• 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

          Jesse Glick created issue -
          Daniel Beck made changes -
          Link New: This issue is related to JENKINS-21574 [ JENKINS-21574 ]

          Daniel Beck added a comment -

          Auto-refresh is a piece of crap and needs to go.

          It also breaks dialogs not designed to work with it (see linked issue), and cancels JS dialogs.

          Daniel Beck added a comment - Auto-refresh is a piece of crap and needs to go. It also breaks dialogs not designed to work with it (see linked issue), and cancels JS dialogs.
          Daniel Beck made changes -
          Link New: This issue is related to JENKINS-10583 [ JENKINS-10583 ]
          Daniel Beck made changes -
          Link New: This issue is related to JENKINS-23470 [ JENKINS-23470 ]

          Oleg Nenashev added a comment - - edited

          Config AutoRefresh Plugin may be extended to support approaches #2 and #3
          https://wiki.jenkins-ci.org/display/JENKINS/Config+AutoRefresh+Plugin
          BTW, seems the changes in the core would be required as well

          It's also possible to implement a ViewProperty::isAutomaticRefreshEnabled() to manage auto-refreshes in view layouts (JENKINS-21191 provides similar feature for custom views)

          Oleg Nenashev added a comment - - edited Config AutoRefresh Plugin may be extended to support approaches #2 and #3 https://wiki.jenkins-ci.org/display/JENKINS/Config+AutoRefresh+Plugin BTW, seems the changes in the core would be required as well It's also possible to implement a ViewProperty::isAutomaticRefreshEnabled() to manage auto-refreshes in view layouts ( JENKINS-21191 provides similar feature for custom views)

          Daniel Beck added a comment -

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

          Daniel Beck added a comment - Isn't "1" why we're discussing Servlet 3 to get SSE?

          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.

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

              Created:
              Updated:
              Resolved: