-
Bug
-
Resolution: Postponed
-
Blocker
-
multijob-plugin 1.25
jenkins 2.46.3
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.
[JENKINS-45021] Reference to builds causes internal inconsistencies and performance issues
R K
created issue -
R K
made changes -
| 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. |
| Resolution | New: Postponed [ 6 ] | |
| Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
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)