-
Bug
-
Resolution: Fixed
-
Critical
https://github.com/jenkinsci/warnings-ng-plugin/blob/77ab5ae4f00222585eef5b24ba43b8b04aa536c7/plugin/src/main/java/io/jenkins/plugins/analysis/core/model/MissingResultFallbackHandler.java#L43-L55 (introduced in https://github.com/jenkinsci/warnings-ng-plugin/pull/1963 potentially forces a controller to load every build of a job from disk. If a job has thousands of historical builds, this can cause a huge amount of I/O traffic and CPU, and then all of these Run objects and associated metadata are held in heap in SoftReference’s, only to be evicted during the next GC cycle.
Noticed because on a particular job in a (CloudBees CI) controller loading a recent build in a browser took around a minute (also blocking some other GUI rendering threads which were waiting for the RunMap lock on the same job):
"Handling GET /job/…/lastFailedBuild/ from … : Jetty (winstone)-39 Run/index.jelly WorkflowRun/sidepanel.jelly Actionable/actions.jelly" Id=39 Group=main WAITING at …CI-specific code… at hudson.model.RunMap.allowLoad(RunMap.java:258) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:578) - locked hudson.model.RunMap@6fcd69f5 at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:537) at jenkins.model.lazy.LazyBuildMixIn$RunMixIn.getPreviousBuild(LazyBuildMixIn.java:406) at PluginClassLoader for workflow-job//org.jenkinsci.plugins.workflow.job.WorkflowRun.getPreviousBuild(WorkflowRun.java:277) at PluginClassLoader for workflow-job//org.jenkinsci.plugins.workflow.job.WorkflowRun.getPreviousBuild(WorkflowRun.java:135) at PluginClassLoader for warnings-ng//io.jenkins.plugins.analysis.core.model.MissingResultFallbackHandler.createFor(MissingResultFallbackHandler.java:43) at PluginClassLoader for warnings-ng//io.jenkins.plugins.analysis.core.model.MissingResultFallbackHandler.createFor(MissingResultFallbackHandler.java:22) at hudson.model.Actionable.createFor(Actionable.java:118) at hudson.model.Actionable.getAction(Actionable.java:335) at PluginClassLoader for pipeline-model-definition//org.jenkinsci.plugins.pipeline.modeldefinition.actions.RestartDeclarativePipelineAction.isRestartEnabled(RestartDeclarativePipelineAction.java:109) at PluginClassLoader for pipeline-model-definition//org.jenkinsci.plugins.pipeline.modeldefinition.actions.RestartDeclarativePipelineAction.getIconFileName(RestartDeclarativePipelineAction.java:79) at …
In OSS Jenkins it would normally be the next line which consumes the most time, but at any rate the point is that no plugin should ever enumerate all builds of a job without some sort of aggressive termination condition. See JENKINS-23945 for a similar fix to junit long ago.
- relates to
-
-
- Resolved
-
- links to