|
||||||||
|
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 |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Actually I suspect that https://github.com/jenkinsci/jenkins/pull/1596 just exposes problems with throttle concurrent builds plugin that were masked.
Throttle concurrent builds "works" by searching for jobs that are running during the QueueTaskDispatcher.canTake evaluation. In Jenkins core, pre: https://github.com/jenkinsci/jenkins/blob/jenkins-1.606/core/src/main/java/hudson/model/Queue.java#L1178 and post: https://github.com/jenkinsci/jenkins/blob/jenkins-607/core/src/main/java/hudson/model/Queue.java#L1352 the QueueTaskDispatcher methods are called for all Buildable jobs in the Queue before mapping any of them against an executor.
Thus https://github.com/jenkinsci/throttle-concurrent-builds-plugin/blob/throttle-concurrents-1.8.4/src/main/java/hudson/plugins/throttleconcurrents/ThrottleQueueTaskDispatcher.java#L194 will always fail to count jobs that are being picked off the queue at the same time.
What the TCB plugin should probably be doing is either:
The code change in 1.607 just removed some of the threading issues that allowed the TCB plugin to work most of the time by accident this bug represents a logical flaw in TCB that could still occur in 1.536-1.606 (most likely if running on a single core master) if the thread sequencing falls just right as Queue.maintain evaluates all projects in Buildable in one chunk and then maps them against executors.
With 1.536-1.606 the executor threads could pick up the tasks while the Queue was in the process of dividing out the atomic set of work assignments, and thus - as long as the executor threads were scheduled fast enough - the TCB plugin would see the work assignments in the process of being assigned (but on a heavily loaded system or a single core system this issue would still occur)
With 1.607 we ensure that the work assignment from Queue.maintain is mapped as an atomic unit, and thus the bug in TCB is exposed always.
At least that is my analysis