[JIRA] (JENKINS-13829) Race condition in Queue.pop()
SCM/JIRA link daemon commented on JENKINS-13829 Race condition in Queue.pop() Code changed in jenkins User: Brad Larson Path: gerrithudsontrigger/src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/GerritTrigger.java http://jenkins-ci.org/commit/gerrit-trigger-plugin/6e9bfee152a01c8a012fba0c54e4990e746b0c2b Log: Fix behavior of canceling old patch sets There were several problems with canceling jobs created by old patch sets when new patch sets are uploaded. We were removing old jobs when scheduled() was called, but then removed() was also called, which would cancel the newly-added build we care about. Instead, we now store the PatchsetCreated event to track the jobs, and cancel all jobs for a particular Change # when a new patch set is uploaded but only remove the exact job when remove() is called. There was also a problem in calling Future.cancel(), as documented in https://issues.jenkins-ci.org/browse/JENKINS-13829. This was worked around by storing the parameters used to create each build and canceling jobs with the same parameters. This is more in-line with how jobs are canceled from the Web UI. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13829) Race condition in Queue.pop()
[ https://issues.jenkins-ci.org/browse/JENKINS-13829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163254#comment-163254 ] SCM/JIRA link daemon commented on JENKINS-13829: Code changed in jenkins User: Brad Larson Path: gerrithudsontrigger/src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/GerritTrigger.java http://jenkins-ci.org/commit/gerrit-trigger-plugin/ef82c75b5ce7433936a57108e1a3f6638093768a Log: Fix behavior of canceling old patch sets There were several problems with canceling jobs created by old patch sets when new patch sets are uploaded. We were removing old jobs when scheduled() was called, but then removed() was also called, which would cancel the newly-added build we care about. Instead, we now store the PatchsetCreated event to track the jobs, and cancel all jobs for a particular Change # when a new patch set is uploaded but only remove the exact job when remove() is called. There was also a problem in calling Future.cancel(), as documented in https://issues.jenkins-ci.org/browse/JENKINS-13829. This was worked around by storing the parameters used to create each build and canceling jobs with the same parameters. This is more in-line with how jobs are canceled from the Web UI. > Race condition in Queue.pop() > - > > Key: JENKINS-13829 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13829 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: bklarson > > I have ran into a race condition with multiple Executors calling Queue.pop() > at the same time. The task's FutureImpl is being told executor A will run > the task, but it ends up running on executor B. Later when I call > FutureImpl.cancel(), the wrong thread is interrupted. If another task is > running on executor A, that task is canceled instead. > I ran into this while trying to fix the GerritTriggerPlugin. The plugin > schedules jobs when code is uploaded to Gerrit. If that change in Gerrit > gets amended, the plugin can cancel the current job before scheduling the new > job. This makes sense, because we no longer care about the results of the > build since that code will no be used. > Because of this behavior, one Executor (B) is running the item and gets > canceled when another Executor (A) starts loading the new item. Executor A > calls Queue.pop(), and in the maintain() call it sets the new item's > FutureImpl's executor to itself (A) and signals the JobOffer's event. In the > mean time, Executor B also calls pop() since its last job has just been > canceled. It ends up getting the JobOffer which A just signaled. Now the > task is running on Executor B but thinks it is running on Executor A. > Is there a work-around to cancel a FutureImpl in this case? Maybe scan > through all Executors to find the one running the task we are interested in? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13829) Race condition in Queue.pop()
bklarson created JENKINS-13829: -- Summary: Race condition in Queue.pop() Key: JENKINS-13829 URL: https://issues.jenkins-ci.org/browse/JENKINS-13829 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: bklarson I have ran into a race condition with multiple Executors calling Queue.pop() at the same time. The task's FutureImpl is being told executor A will run the task, but it ends up running on executor B. Later when I call FutureImpl.cancel(), the wrong thread is interrupted. If another task is running on executor A, that task is canceled instead. I ran into this while trying to fix the GerritTriggerPlugin. The plugin schedules jobs when code is uploaded to Gerrit. If that change in Gerrit gets amended, the plugin can cancel the current job before scheduling the new job. This makes sense, because we no longer care about the results of the build since that code will no be used. Because of this behavior, one Executor (B) is running the item and gets canceled when another Executor (A) starts loading the new item. Executor A calls Queue.pop(), and in the maintain() call it sets the new item's FutureImpl's executor to itself (A) and signals the JobOffer's event. In the mean time, Executor B also calls pop() since its last job has just been canceled. It ends up getting the JobOffer which A just signaled. Now the task is running on Executor B but thinks it is running on Executor A. Is there a work-around to cancel a FutureImpl in this case? Maybe scan through all Executors to find the one running the task we are interested in? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
