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

MavenModuleSetBuild.getResult is expensive



    • Similar Issues:


      MavenModuleSetBuild.getResult looks for the worst result of any of the last builds of the component modules. If you are using Maven 2, some of these might have been run after the MavenModuleSetBuild itself completed, either because you build modules in parallel, or because you manually rebuilt one of the modules; in such cases the result of the module set can be retroactively worsened. (Although Run.setResult is only permitted while building, getResult is nonfinal, effectively a backdoor to get around that restriction.)

      Besides the logical confusion over whether a given build of a job was successful or not, this logic is very problematic for lazy-loading:

      at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:496) 
      at hudson.model.AbstractProject.getNearestOldBuild(AbstractProject.java:1067) 
      at hudson.maven.MavenModuleSetBuild.getModuleLastBuilds(MavenModuleSetBuild.java:434) 
      at hudson.maven.MavenModuleSetBuild.getResult(MavenModuleSetBuild.java:189) 
      at hudson.model.PermalinkProjectAction$Permalink$3.apply(PermalinkProjectAction.java:134) 
      at jenkins.model.PeepholePermalink.resolve(PeepholePermalink.java:95) 
      at hudson.model.Job.getLastSuccessfulBuild(Job.java:802)

      For example, every time the Maven job is displayed in a view, getResult is called at least once for the icon color. (Probably also to verify the permalink even when the symlink such as lastSuccessfulBuild exists, which after JENKINS-16023 it should.) But this forces the most recent build of each module to be loaded, too, and if there are a lot of modules that can take significant time, either after startup or after some have been evicted from memory.

      Not clear what can be done here. Options:

      1. Delete this override and break functional compatibility. Means that jobs using parallel module building will not show meaningful status.
      2. Suppress the override in case the job is currently configured to use Maven 3, which does not support the trigger conditions to begin with. But it is not trivial to tell this; a MavenInstallation will resolve to a specific version only during a build (it might not exist at all on the master).
      3. Store the current effective result in build.xml and use some listener to update it after relevant module builds.


          Issue Links


            jglick Jesse Glick created issue -
            scm_issue_link SCM/JIRA link daemon made changes -
            Field Original Value New Value
            Resolution Fixed [ 1 ]
            Status Open [ 1 ] Resolved [ 5 ]
            jglick Jesse Glick made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            scm_issue_link SCM/JIRA link daemon made changes -
            Resolution Fixed [ 1 ]
            Status Reopened [ 4 ] Resolved [ 5 ]
            teilo James Nord made changes -
            Labels lazy-loading performance lazy-loading lts-candidate performance
            olivergondza Oliver Gondža made changes -
            Labels lazy-loading lts-candidate performance lazy-loading lts-1.509.3-fixed performance
            olivergondza Oliver Gondža made changes -
            Labels lazy-loading lts-1.509.3-fixed performance 1.509.3-fixed lazy-loading performance
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-25075 [ JENKINS-25075 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 150342 ] JNJira + In-Review [ 193477 ]


              Unassigned Unassigned
              jglick Jesse Glick
              0 Vote for this issue
              4 Start watching this issue