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

Reference to builds causes internal inconsistencies and performance issues


      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.

            Unassigned Unassigned
            rk R K
            0 Vote for this issue
            2 Start watching this issue