-
Bug
-
Resolution: Fixed
-
Critical
Merely calling job.getBuilds().isEmpty() breaks lazy-loading:
at hudson.model.Run.onLoad(Run.java:319) at hudson.model.RunMap.retrieve(RunMap.java:226) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:667) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:650) at jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:602) at jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:264) at java.util.AbstractMap$2$1.<init>(AbstractMap.java:378) at java.util.AbstractMap$2.iterator(AbstractMap.java:377) at hudson.util.RunList$2.iterator(RunList.java:213) at hudson.util.RunList.iterator(RunList.java:103) at hudson.util.RunList.isEmpty(RunList.java:173)
You would reasonably expect this method, and anything simply iterating builds, to be lazy, but it is eager.
- depends on
-
JENKINS-25655 AbstractLazyLoadRunMap.entrySet improperly cached
-
- Resolved
-
- is blocking
-
JENKINS-20892 /{view,computer,user}/*/builds & /job/*/buildTimeTrend block HTTP response on build record loading
-
- Resolved
-
- is duplicated by
-
JENKINS-23244 Slave build history page has no data and spawns a ton of very long-lived blocking threads on the master
-
- Resolved
-
- is related to
-
JENKINS-8754 ROADMAP: Improve Start-up Time
-
- Closed
-
[JENKINS-18065] AbstractLazyLoadRunMap.iterator() calls .all()
Link |
New:
This issue is related to |
Labels | Original: lts-candidate performance | New: lazy-loading lts-candidate performance |
Link |
New:
This issue is blocking |
Assignee | New: Kohsuke Kawaguchi [ kohsuke ] |
Seems to me that AbstractLazyLoadRunMap.all could simply create an empty BuildReference for each ID on disk, rather than calling load. Then the entrySet would have the right keys, and if and when you actually tried to access a value for an entry, BuildReferenceMapAdapter.unwrap would call getById and thus load for that one build. Right?