提交 5880ed83 编写于 作者: S Stephen Connolly

[FIXED JENKINS-27708][FIXED JENKINS-27871] Ensure that identification of...

[FIXED JENKINS-27708][FIXED JENKINS-27871]  Ensure that identification of blocked tasks is using the live state.

- The creation of a snapshot itself should be relatively cheap given the expected rate of
  job execution. You probably would need 100's of jobs starting execution every iteration
  of maintain() before this could even start to become an issue and likely the calculation
  of isBuildBlocked(p) will become a bottleneck before updateSnapshot() will. Additionally
  since the snapshot itself only ever has at most one reference originating outside of the stack
  it should remain in the eden space and thus be cheap to GC.

- JENKINS-27708 comments 225819 and 225906 provide more complex but logically equivalent fixes of
  this issue. I am favouring this approach as it is simpler and provides less scope for error as any
  new helper methods can just rely on the snapshot being up to date whereas with the other
  two candidates if a new helper method is introduced there is the potential to miss adding support
  for the live view. The comment 225819 has the risk of introducing extra lock contention while
  the comment 225906 version forces every access to the helper methods to pass a second memory
  barrier
上级 64465feb
......@@ -1335,7 +1335,10 @@ public class Queue extends ResourceController implements Saveable {
final QueueSorter s = sorter;
if (s != null)
s.sortBuildableItems(buildables);
// Ensure that identification of blocked tasks is using the live state: JENKINS-27708 & JENKINS-27871
updateSnapshot();
// allocate buildable jobs to executors
for (BuildableItem p : new ArrayList<BuildableItem>(
buildables)) {// copy as we'll mutate the list in the loop
......@@ -1372,6 +1375,18 @@ public class Queue extends ResourceController implements Saveable {
makePending(p);
else
LOGGER.log(Level.FINE, "BuildableItem {0} with empty work units!?", p);
// Ensure that identification of blocked tasks is using the live state: JENKINS-27708 & JENKINS-27871
// The creation of a snapshot itself should be relatively cheap given the expected rate of
// job execution. You probably would need 100's of jobs starting execution every iteration
// of maintain() before this could even start to become an issue and likely the calculation
// of isBuildBlocked(p) will become a bottleneck before updateSnapshot() will. Additionally
// since the snapshot itself only ever has at most one reference originating outside of the stack
// it should remain in the eden space and thus be cheap to GC.
// See https://issues.jenkins-ci.org/browse/JENKINS-27708?focusedCommentId=225819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-225819
// or https://issues.jenkins-ci.org/browse/JENKINS-27708?focusedCommentId=225906&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-225906
// for alternative fixes of this issue.
updateSnapshot();
}
} finally { updateSnapshot(); } } finally {
lock.unlock();
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册