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

Reference to builds causes internal inconsistencies and performance issues

    Details

    • Similar Issues:

      Description

      Each MultiJob build contains serialized references to subjob's builds. This is very, very evil because:

      • the XML of the build is unnecessarily large, as it contains the complete downstream builds
      • loading the build effectively reloads all downstream builds
      • ... but from a different source, so you might end up with different Build objects for the same build, which leads to one of them having a parent of null, leading to wierd NPEs down the line.

      Luckily, this is easy to fix:

      • Make the build field transient and non-final.
      • Add a final String buildid.
      • On construction, set buildid to build.getExternalizableId() unless it is null.
      • In the getBuild() method, first check if build is null, but buildid is not (which is the case after deserialization). Get Run.fromExternalizableId(buildid), if it is an AbstractBuild, assign to build.
      • Don't do this at deserialization time. This will cause issues if relevant builds have not been fully loaded yet.

      While we're at it, make the MultiJobAction in MultiJobBuilder a static class. Otherwise, the surrounding class is also serialized into the XML, and a surrounding object is recreated that is not even used and cannot be accessed.

        Attachments

          Activity

          Hide
          yorammi Yoram Michaeli added a comment -

          Closing issue as part of tikal-multijob-plugin issues cleanup.
          If still relevant, please open a matching issue in https://github.com/jenkinsci/tikal-multijob-plugin/issues (you can refer to this issue in its description)

          Show
          yorammi Yoram Michaeli added a comment - Closing issue as part of tikal-multijob-plugin issues cleanup. If still relevant, please open a matching issue in https://github.com/jenkinsci/tikal-multijob-plugin/issues (you can refer to this issue in its description)

            People

            • Assignee:
              Unassigned
              Reporter:
              rk R K
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: