|
||||||||||||
|
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.
Tried various things in PR 27, but as explained there, the result is not satisfactory. I suspect JENKINS-27708 needs to be addressed first.
My fear is that the current basic design of ThrottleQueueTaskDispatcher just cannot be made to scale well. I wonder if it would be better to invert the logic: implement ExecutorListener (as a second extension) to track what is running in each category, keeping a map from nodes to a histogram of task counts running by category (WeakHashMap<Node,HashMap<String,Integer>>?). Then canTake/canRun would only need to look up configuration for the proposed job, and do a table lookup to see the current count and compare that to the configured limit.
I am not sure how that would relate to JENKINS-27708. ExecutorListener seems to be called with the Queue lock held, which is good, but that problem seems to stem from QueueTaskDispatcher being asked to make decisions about multiple jobs before any of them are actually scheduled. The call to taskAccepted does come from new WorkUnitContext, within maintain, so the question is whether this is interleaved with QueueTaskDispatcher calls, or after all of them have completed.