[FIXED JENKINS-28446] - proper calculation of queue length in UnlabeledLoadStatistics

[oleg-nenashev]

https://issues.jenkins-ci.org/browse/JENKINS-28446

UnlabeledLoadStatistics:: computeQueueLength() was broken starting from the first release (reason - wrong assumption due to the undocumented behavior of Queue::countBuildableItemsFor()). There's n impact on cloud provisioners if a job has no label definitions.

The fix enforces a filtering of queue items with labels. Backporting to the current LTS is required IMO.

@reviewbybees @recampbell

[stephenc]

You've implemented the old API not the new one

[stephenc]

So what you really need to do is fix Queue.countBuildableItemsFor(null)... which sadly has a dual usage mode. I suspect we want to introduce Queue.strictCountBuildableItemsFor(label) as the existing one has additional symantics for null arguments

[oleg-nenashev]

You've implemented the old API not the new one

The old API is still being by external callers. The "modern" API will be use filters (which are correct) or be defaulted to the call I've fixed

So what you really need to do is fix Queue.countBuildableItemsFor(null)... which sadly has a dual usage mode. I suspect we want to introduce Queue.strictCountBuildableItemsFor(label) as the existing one has additional symantics for null arguments

This change is definitely useful as an extra patch, but it does not replace the fix for the Old API, which should be back-portable to 1.609

[stephenc]

You should not be iterating the Queue from the load stats

You should be using the snapshot in Queue.

af55e53 was the commit that broke countBuildableItemsFor in this regard

[stephenc]

By doing the iteration in ULS you force the allocation of a new array list. Much better to just have a correct method in Queue and call that. Some investigation is required to determine why af55e53 needed to count tasks with no assigned label as being valid for a specific label

[oleg-nenashev]

You should not be iterating the Queue from the load stats. You should be using the snapshot in Queue.

Queue::getBuildableItems() returns an array from the snapshot, hence it should be OK.

Some investigation is required to determine why af55e53 needed to count tasks with no assigned label as being valid for a specific label

I suppose the committer just wanted to use this method in Queue::countBuildableItems()

By doing the iteration in ULS you force the allocation of a new array list. Much better to just have a correct method in Queue and call that.

I'll introduce such API method. BTW, the current implementation should be backported to the previous LTS, hence I propose to add a separate commit w/o squashing it

[stephenc]

Well if you want to backport a fix it should be a different fix for pre 1.607

Don't mess up the tuned code in 1.607+ just because you want to backport the fix to pre 1.607. Create a pull request against the specific branch and fix master the right way

[oleg-nenashev]

Well if you want to backport a fix it should be a different fix for pre 1.607

It will be back-ported to 1.609.x, so there's no need in the completely different fix

[stephenc]

Then fix it right. Don't count in the ULS count in Queue and just invoke the method direct to save spinning out an Array List

[oleg-nenashev]

@stephenc
Done

[stephenc]

👍 but I would prefer if we could find out why countBuildabelItemsFor needs the special counting of items with a null label

[oleg-nenashev]

@stephenc
I suppose in af55e53 @aklochkovgd used such hack to calculate all buildable items. This hack has not been noticed by PR reviewers, and the change has been merged. There was no buzz regarding regressions after the merge.

Any hack becomes a "feature" after 2 years, so I would not revert the existing behavior

[stephenc]

Well it would be good to document why in the code

[tfennelly]

👍 in so much as I get the problem

[stephenc]

👍