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
