Throttling flyweight tasks

[dsavenko]

Hi,

This pull request enables throttling flyweights tasks. No new UI's added, but now if a user turns on throttling for a flyweight job, it works.

Some bits of explanation:

1. Throttling logic is not changed. It's only moved to the Throttler class. This is done because I need it in two places.
2. Since QueueTaskDispatcher is not called for flyweights, I use the NodeProperty's canTake() instead. There is a gap between returning from canTake() and the build being assigned to some node (leave the queue). Another throttle subject may come to this node in this gap, which can result in throttling condition being violated. This is why I needed a static lock. With this lock, I make sure we don't make any actual decisions about throttling until the previous build actually leaves the queue.
3. I need ThrottleNodeProperty to be present in all nodes, so automatically add it to each node on every computer change.
4. Behaviour is not changed for non-flyweight tasks.
5. I changed the Jenkins target version to 1.609.3, since earlier we agreed it's OK (see Reduce applicability requirements #32).

I realise the implementation's somewhat unusual. But I spent some time studying the Jenkins code and didn't found any other options to throttle flyweight tasks. Probably throttling flyweights usually doesn't make much sense. But we have real cases when it does.

Please, share your thoughts.

[jenkinsadmin]

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.

[oleg-nenashev]

needs a review

[damphyr]

Hi all.
I've been trying to use this to throttle jobs executed from a pipeline job and the throttling does not work.
Would this PR solve the problem?

The problem I ran into in detail:

I have a job (batch) which starts several parametrized instances of another job (compile).

I want to limit the number of nodes the compile job runs on, so I configured it with throttle-concurrent:

pipelineJob("Compile")
{
  concurrentBuild(true);
  throttleConcurrentBuilds {
    maxPerNode(1)
    maxTotal(3)
  }
  parameters {
    stringParam('TARGET', 'TGT', 'The target to compile')
  }
  environmentVariables {
    keepSystemVariables(true);
    keepBuildVariables(true);
  }
  definition {
    cps {
      script(readFileFromWorkspace('pipelines/compile.groovy'))
    }
  }

If I start them manually, the throttling works. The batch job is another pipeline definition:

def targets=["TGT1","TGT2","TGT3","TGT4","TGT5"]
def jobs=[:]
for(int i = 0; i < targets.size(); i++)
{
  def target= targets.get(i)
  println "triggering compilation for ${targets}"
  jobs[region]={
    build job: 'Compile', parameters: [[$class: 'StringParameterValue', name: 'TARGET', value: region]]
  }
}
parallel jobs

When this is triggered then I get all 5 compile jobs running immediately where I would expect execution to be throttled down to 3 nodes

[sshelomentsev]

Hi @damphyr
Yes, this PR solve the problem with throttling concurrent jobs in the pipeline.

[oleg-nenashev]

I doubt it completely solves the throttling topic, at least for parallel() pipeline invocations. In general, this PR definitely deserves some attention from maintainers and integration. Node throttling approach rework is also reasonable.

Sorry about dropping a ball on it.

[iaroslav42]

Hi, I've merged master into our branch and made some minor improvements. Could you please review it?
Just to clarify, #46 doesn't supersede this one

[mamh2021]

any update???

[ggkochanski]

@damphyr can you check if adding quietPeriod to build() doesn't help accidently?
e.g.
build job: 'Compile', quietPeriod: 3, parameters: [[$class: 'StringParameterValue', name: 'TARGET', value: region]]