• Type: Bug
• Resolution: Postponed
• Priority: Blocker
• Component/s: multijob-plugin
• Labels:

  • NPE
  • NullPointerException
  • performance
  • serialization
• Environment:

  multijob-plugin 1.25
  jenkins 2.46.3

[JENKINS-45021] Reference to builds causes internal inconsistencies and performance issues

R K created issue - 2017-06-21 08:57

R K made changes - 2017-06-21 08:57

Description

Original: 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's build  * 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.

New: 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.

Yoram Michaeli made changes - 2018-06-08 16:05

Resolution		New: Postponed [ 6 ]
Status	Original: Open [ 1 ]	New: Closed [ 6 ]