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

/{view,computer,user}/*/builds & /job/*/buildTimeTrend block HTTP response on build record loading

      Computer/builds.jelly calls Computer.getBuilds which first looks up all Job instances—probably not too expensive—then creates a merged RunList from them—again OK, as this is lazy—then calls the node(Node) filter. The filter is incremental, but if most builds were not on this computer, it would load many more than the limit of 50 in t:buildListTable before it finds some to display.

      Trimming the merged list before filtering would solve that problem (making this perform much like View/builds.jelly), but then you might not see anywhere near 50 builds, or indeed any at all, even when there are some (older) builds run on this computer.

      User/builds.jelly calls User.getBuilds which does not even bother using an incremental filter. It does use newBuilds to limit how many builds are considered per job, but then scans all of those at once for mentions of the current user.

      Ideally all such displays would show all applicable builds, but use ProgressiveRendering so that build records are only loaded in a background thread and only so long as you keep the page open. (Compare AsynchPeople.)

          [JENKINS-20892] /{view,computer,user}/*/builds & /job/*/buildTimeTrend block HTTP response on build record loading

          Jesse Glick created issue -

          Jesse Glick added a comment - - edited

          Actually it looks like even /view/*/builds is wrong: t:buildListTable truncates builds using Functions.subList, which to comply with the contract of List calls size, which on RunList forces all builds to be loaded!

          Jesse Glick added a comment - - edited Actually it looks like even /view/*/builds is wrong: t:buildListTable truncates builds using Functions.subList , which to comply with the contract of List calls size , which on RunList forces all builds to be loaded!
          Jesse Glick made changes -
          Priority Original: Major [ 3 ] New: Critical [ 2 ]
          Summary Original: /computer/*/builds and /user/*/builds block HTTP response on build record loading New: /{view,computer,user}/*/builds block HTTP response on build record loading

          Jesse Glick added a comment -

          /view/*/builds and /computer/*/builds (but strangely enough not /user/*/builds) complicate the issue by using a BuildTimelineWidget, which seems incompatible with lazy loading.

          Jesse Glick added a comment - /view/*/builds and /computer/*/builds (but strangely enough not /user/*/builds ) complicate the issue by using a BuildTimelineWidget , which seems incompatible with lazy loading.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-18992 [ JENKINS-18992 ]

          Jesse Glick added a comment -

          For User the RSS feeds are also bad; rssAll and rssFailed suffer from the same problem as builds. rssLatest is even worse: it will load every build of a job (not just newBuilds) unless and until it finds one associated with this user.

          Jesse Glick added a comment - For User the RSS feeds are also bad; rssAll and rssFailed suffer from the same problem as builds . rssLatest is even worse: it will load every build of a job (not just newBuilds ) unless and until it finds one associated with this user.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/java/hudson/util/RunList.java
          http://jenkins-ci.org/commit/jenkins/a586609c4a2f2083a7f40a6055776afbf2b1f1c7
          Log:
          JENKINS-20892 Noting that RunList.getFirstBuild (used by BuildTimelineWidget) breaks lazy loading.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/java/hudson/util/RunList.java http://jenkins-ci.org/commit/jenkins/a586609c4a2f2083a7f40a6055776afbf2b1f1c7 Log: JENKINS-20892 Noting that RunList.getFirstBuild (used by BuildTimelineWidget) breaks lazy loading.

          Jesse Glick added a comment -

          For BuildTimelineWidget/control.jelly, it seems that DefaultEventSource.loadJSON can display new events incrementally, which would be compatible with ProgressiveRendering with some work. getFirstBuild must not be used, meaning that timeline_start cannot be set in advance, or can be set only to some very old value, or can be incrementally moved backward.

          Job/buildTimeTrend.jelly also uses BuildTimelineWidget, and anyway it iterates all builds of the job.

          Jesse Glick added a comment - For BuildTimelineWidget/control.jelly , it seems that DefaultEventSource.loadJSON can display new events incrementally, which would be compatible with ProgressiveRendering with some work. getFirstBuild must not be used, meaning that timeline_start cannot be set in advance, or can be set only to some very old value, or can be incrementally moved backward. Job/buildTimeTrend.jelly also uses BuildTimelineWidget , and anyway it iterates all builds of the job.

          Jesse Glick added a comment -

          …and Job/buildTimeTrend.jelly calls Job.buildTimeGraph, which again iterates all builds (though asynchronously during an image load).

          Jesse Glick added a comment - …and Job/buildTimeTrend.jelly calls Job.buildTimeGraph , which again iterates all builds (though asynchronously during an image load).
          Jesse Glick made changes -
          Summary Original: /{view,computer,user}/*/builds block HTTP response on build record loading New: /{view,computer,user}/*/builds & /job/*/buildTimeTrend block HTTP response on build record loading

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: