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?