[
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
