-
Bug
-
Resolution: Fixed
-
Minor
-
-
2.36
Was running a CloudBees Core 2.204.1.1 managed master. Restarted the master; I think there was a build running which had a node block with an unsatisfied label. At any rate, restart was very slow, and in the course of inspecting thread dumps during startup I noticed something which looked inappropriate:
"jenkins.util.Timer [#3]" ... waiting for monitor entry ... java.lang.Thread.State: BLOCKED (on object monitor) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:371) - waiting to lock <...> (a hudson.model.RunMap) at jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:228) at org.jenkinsci.plugins.workflow.job.WorkflowJob.getBuildByNumber(WorkflowJob.java:232) at org.jenkinsci.plugins.workflow.job.WorkflowJob.getBuildByNumber(WorkflowJob.java:103) at hudson.model.Run.fromExternalizableId(Run.java:2446) at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.runForDisplay(ExecutorStepExecution.java:503) at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.getOwnerTask(ExecutorStepExecution.java:436) at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.getAffinityKey(ExecutorStepExecution.java:600) at hudson.model.LoadBalancer$1.assignGreedily(LoadBalancer.java:119) at hudson.model.LoadBalancer$1.map(LoadBalancer.java:107) at hudson.model.LoadBalancer$2.map(LoadBalancer.java:167) at hudson.model.Queue.maintain(Queue.java:1640) at hudson.model.Queue$MaintainTask.doRun(Queue.java:2898) at ...
Here getAffinityKey is waiting to load a build record (Run object) merely to determine the name of the owning job, which is silly since this information is available simply from the runId.
- causes
-
-
- Resolved
-
- is caused by
-
JENKINS-36547 Queue.Task.getFullDisplayName is a poor choice of key for LoadBalancer.CONSISTENT_HASH
-
- Resolved
-
- links to