Setup is the same as in JENKINS-23945 except use the testng branch of the sample project, and configure the TestNG plugin's publisher with **/target/surefire-reports/testng-results.xml. Even with the fix of JENKINS-23945 applied to Jenkins core, after displaying the job index page all builds are loaded:

      ... FINER hudson.model.Run
      reload lazy-load-perf #71 @...
      ... FINEST hudson.model.RunMap
      Loaded lazy-load-perf #71
      hudson.model.RunMap$ThisIsHowItsLoaded
      	at hudson.model.RunMap.retrieve(RunMap.java:221)
      	at hudson.model.RunMap.retrieve(RunMap.java:56)
      	at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688)
      	at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:650)
      	at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:382)
      	at jenkins.model.lazy.LazyLoadRunMapEntrySet$1.next(LazyLoadRunMapEntrySet.java:70)
      	at jenkins.model.lazy.LazyLoadRunMapEntrySet$1.next(LazyLoadRunMapEntrySet.java:59)
      	at java.util.AbstractMap$2$1.next(AbstractMap.java:385)
      	at hudson.util.RunList.size(RunList.java:108)
      	at hudson.plugins.testng.TestNGProjectAction.newGraphNotNeeded(TestNGProjectAction.java:141)
      	at hudson.plugins.testng.TestNGProjectAction.doGraph(TestNGProjectAction.java:114)
      	at ...
      

      The problem is TestNGProjectAction.newGraphNotNeeded calling RunList.size, which is deprecated since it forces all builds to be loaded immediately.

          [JENKINS-24176] Test result trend breaks lazy-loading

          Jesse Glick added a comment -

          “Introduced by” the fix for JENKINS-9839, though there was no lazy-loading at the time this fix was made so it was not manifested as a regression at the time.

          Jesse Glick added a comment - “Introduced by” the fix for JENKINS-9839 , though there was no lazy-loading at the time this fix was made so it was not manifested as a regression at the time.

          Jesse Glick added a comment -

          Experimenting with reverting the fix of JENKINS-9839. While that issue might be an annoyance in unusual cases, it is minor compared to the lazy-loading problem, which can bring a large Jenkins installation to a grinding halt—just because someone opened a job index page in a browser. Now the next problem appears:

          hudson.model.RunMap$ThisIsHowItsLoaded
          	at hudson.model.RunMap.retrieve(RunMap.java:221)
          	at hudson.model.RunMap.retrieve(RunMap.java:56)
          	at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688)
          	at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:650)
          	at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:382)
          	at jenkins.model.lazy.LazyBuildMixIn$RunMixIn.getPreviousBuild(LazyBuildMixIn.java:366)
          	at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:198)
          	at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:106)
          	at hudson.model.Run.getPreviousCompletedBuild(Run.java:819)
          	at hudson.plugins.testng.TestNGProjectAction.populateDataSetBuilder(TestNGProjectAction.java:187)
          	at hudson.plugins.testng.TestNGProjectAction.doGraph(TestNGProjectAction.java:112)
          	at …
          

          Jesse Glick added a comment - Experimenting with reverting the fix of JENKINS-9839 . While that issue might be an annoyance in unusual cases, it is minor compared to the lazy-loading problem, which can bring a large Jenkins installation to a grinding halt—just because someone opened a job index page in a browser. Now the next problem appears: hudson.model.RunMap$ThisIsHowItsLoaded at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:56) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:650) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:382) at jenkins.model.lazy.LazyBuildMixIn$RunMixIn.getPreviousBuild(LazyBuildMixIn.java:366) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:198) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:106) at hudson.model.Run.getPreviousCompletedBuild(Run.java:819) at hudson.plugins.testng.TestNGProjectAction.populateDataSetBuilder(TestNGProjectAction.java:187) at hudson.plugins.testng.TestNGProjectAction.doGraph(TestNGProjectAction.java:112) at …

          Jesse Glick added a comment -

          This latter problem is essentially identical to JENKINS-23945 and should be solvable in the same way: by declining to display results for builds which have not yet been loaded for some other reason (such as the BuildHistoryWidget).

          Jesse Glick added a comment - This latter problem is essentially identical to JENKINS-23945 and should be solvable in the same way: by declining to display results for builds which have not yet been loaded for some other reason (such as the BuildHistoryWidget ).

          Jesse Glick added a comment -

          Note that MethodResult.populateDataSetBuilder also searches backward in history, but limited to at most 10 builds, so it is not much of a problem.

          Loaded lazy-load-perf #119 in Handling GET /jenkins/job/lazy-load-perf/129/testngreports/test/SomeTest/test1/graph : btpool0-5
          hudson.model.RunMap$ThisIsHowItsLoaded
          	at hudson.model.RunMap.retrieve(RunMap.java:221)
          	at hudson.model.RunMap.retrieve(RunMap.java:56)
          	at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688)
          	at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:650)
          	at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:382)
          	at jenkins.model.lazy.LazyBuildMixIn$RunMixIn.getPreviousBuild(LazyBuildMixIn.java:366)
          	at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:198)
          	at hudson.plugins.testng.results.MethodResult.populateDataSetBuilder(MethodResult.java:305)
          	at hudson.plugins.testng.results.MethodResult.getGraph(MethodResult.java:276)
          	at hudson.plugins.testng.results.MethodResult.doGraph(MethodResult.java:238)
          	at …
          

          Jesse Glick added a comment - Note that MethodResult.populateDataSetBuilder also searches backward in history, but limited to at most 10 builds, so it is not much of a problem. Loaded lazy-load-perf #119 in Handling GET /jenkins/job/lazy-load-perf/129/testngreports/test/SomeTest/test1/graph : btpool0-5 hudson.model.RunMap$ThisIsHowItsLoaded at hudson.model.RunMap.retrieve(RunMap.java:221) at hudson.model.RunMap.retrieve(RunMap.java:56) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:650) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:382) at jenkins.model.lazy.LazyBuildMixIn$RunMixIn.getPreviousBuild(LazyBuildMixIn.java:366) at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:198) at hudson.plugins.testng.results.MethodResult.populateDataSetBuilder(MethodResult.java:305) at hudson.plugins.testng.results.MethodResult.getGraph(MethodResult.java:276) at hudson.plugins.testng.results.MethodResult.doGraph(MethodResult.java:238) at …

          Jesse Glick added a comment -

          Filed PR 13 with proposed fix.

          Jesse Glick added a comment - Filed PR 13 with proposed fix.

          Nalin Makar added a comment -

          Jesse,

          What would be the pros/cons of just doing something similar to MethodResult.populateDataSetBuilder and loading the last 10 builds to generate the trend graph?

          Nalin Makar added a comment - Jesse, What would be the pros/cons of just doing something similar to MethodResult.populateDataSetBuilder and loading the last 10 builds to generate the trend graph?

          Jesse Glick added a comment -

          You could use only the last 10 builds, though this would give less a useful graph: you might as well display information for builds you have at hand. The only “pro” I can think of is that the behavior is more consistent because it would always be showing the last 10 (or however many) builds regardless of what Jenkins had been doing before.

          Note that the build history widget loads the most recent 30 builds when you view the job index page, so these would usually be in memory anyway.

          The JENKINS-23945 fix, for JUnit results, is to display the trend for loaded builds. (More precisely, for all builds starting with the most recent and continuing backwards so long as they exist on disk and are loaded in memory.)

          Jesse Glick added a comment - You could use only the last 10 builds, though this would give less a useful graph: you might as well display information for builds you have at hand. The only “pro” I can think of is that the behavior is more consistent because it would always be showing the last 10 (or however many) builds regardless of what Jenkins had been doing before. Note that the build history widget loads the most recent 30 builds when you view the job index page, so these would usually be in memory anyway. The JENKINS-23945 fix, for JUnit results, is to display the trend for loaded builds. (More precisely, for all builds starting with the most recent and continuing backwards so long as they exist on disk and are loaded in memory.)

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/hudson/plugins/testng/TestNGProjectAction.java
          http://jenkins-ci.org/commit/testng-plugin-plugin/feddedd3e7fa00c22cb7950661380c8f1520c5e6
          Log:
          [FIXED JENKINS-24176] Avoid loading builds from disk just to display test result trend.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/plugins/testng/TestNGProjectAction.java http://jenkins-ci.org/commit/testng-plugin-plugin/feddedd3e7fa00c22cb7950661380c8f1520c5e6 Log: [FIXED JENKINS-24176] Avoid loading builds from disk just to display test result trend.

          Code changed in jenkins
          User: Nalin Makar
          Path:
          src/main/java/hudson/plugins/testng/TestNGProjectAction.java
          http://jenkins-ci.org/commit/testng-plugin-plugin/04fbebb13fba94bb40f695dd807908a81d19bb6a
          Log:
          Merge branch 'JENKINS-24176lazy-load' of https://github.com/jglick/testng-plugin-plugin into jglickJENKINS-24176-lazy-load

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nalin Makar Path: src/main/java/hudson/plugins/testng/TestNGProjectAction.java http://jenkins-ci.org/commit/testng-plugin-plugin/04fbebb13fba94bb40f695dd807908a81d19bb6a Log: Merge branch ' JENKINS-24176 lazy-load' of https://github.com/jglick/testng-plugin-plugin into jglick JENKINS-24176 -lazy-load

          Nalin Makar added a comment -

          Thanks for the information. I have merged the pull request and will do a release sometime today.

          Nalin Makar added a comment - Thanks for the information. I have merged the pull request and will do a release sometime today.

            nullin Nalin Makar
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: