Job assign priority

[pythonerdog]

This change primarily addresses the issue of task priority allocation, ensuring that higher-priority tasks are assigned first.

The current problem does not guarantee higher-priority task allocation in the following scenarios:
server_con->worker_list contains worker1 and worker2; worker1 has a medium-priority task, and worker2 has a high-priority task. The function will assign the medium-priority task when looping to worker1 and then break.

In our production environment, some lower priority Jenkins jobs were triggered eailer than higher. Configuration like this:
Jenkins has servral nodes (instance running test), each node can be configured servral executors and labels. Jenkins job use labels to select nodes to run jobs, one job can be configured more than one label and many jobs can be configured to the same label.
Jenkins gearman plugin as the interface to gearman server, which register functions to gearman server.
https://plugins.jenkins.io/gearman-plugin/

[esabol]

Thank you very much for your contribution, @pythonerdog @huamxu. These changes make sense to me, and all tests pass. That said, I don't use task priorities at all in my gearmand usage, so I'm a bit uncomfortable merging without getting a second opinion from @SpamapS.

[pythonerdog]

Thank you very much for your contribution, @pythonerdog @huamxu. These changes make sense to me, and all tests pass. That said, I don't use task priorities at all in my gearmand usage, so I'm a bit uncomfortable merging without getting a second opinion from @SpamapS.

@esabol Thanks for your feedback. Further review is needed to make sure it works without any impacts

[esabol]

Have you tested this with and without using the --round-robin option, @pythonerdog ?

[SpamapS]

Yeah the scenario described is exactly the scenario round robin was introduced to handle. Will try and find some time to take a closer look this week.

…

On Mon, Nov 3, 2025, 12:29 PM Ed Sabol ***@***.***> wrote: *esabol* left a comment (gearman/gearmand#431) <#431 (comment)> Have you tested this with and without using the --round-robin option, @pythonerdog <https://github.com/pythonerdog> ? — Reply to this email directly, view it on GitHub <#431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADS6YHDR6PE6DHSZ7QUG3D326UKFAVCNFSM6AAAAACKYCLM3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIOBSGQ3TCNRWGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pythonerdog]

Have you tested this with and without using the --round-robin option, @pythonerdog ?

Considering keep the round-robin feature not unaffected and test without using the --round-robin option.
I will do more tests with it, update later here

[SpamapS]

Honestly, I think it may be time for us to make a release that makes round-robin the default. It's hard to even describe the default behavior. "Ignore priority if there are two queues" seems pretty counter-intuitive.

…

On Mon, Nov 3, 2025 at 11:27 PM pythonerdog ***@***.***> wrote: *pythonerdog* left a comment (gearman/gearmand#431) <#431 (comment)> Have you tested this with and without using the --round-robin option, @pythonerdog <https://github.com/pythonerdog> ? Considering keep the round-robin feature not unaffected and test without using the --round-robin option. I will do more tests with it, update later here — Reply to this email directly, view it on GitHub <#431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADS6YHMLQXBSWSPFMTZUHT33BIOPAVCNFSM6AAAAACKYCLM3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIOBUGI2DGMRXGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pythonerdog]

I have done the test with disabled / enabled round-robin in the business QA env (code review by CICD tool zuul https://zuul-ci.org/).

Priority: normal for check pipeline, high for gate pipeline.
Worker: 3 merger worker registered as gearman worker
each Gerrit change review will a merger task.
3 Gerrit change reviews run on check pipeline, 4 reviews run on gate pipeline

disabled round-robin:
merger_1: assigned 4 tasks
merger_2: assigned 2 tasks
merger_3: assigned 1 tasks

enabled round-robin:
merger_1: assigned 3 tasks
merger_2: assigned 2 tasks
merger_3: assigned 2 tasks

I think this code will not affect the current round-robin feature.

[esabol]

I think this code will not affect the current round-robin feature.

That wasn't my concern exactly, @pythonerdog. If I understand correctly, @SpamapS is saying that using the --round-robin option achieves the same (or at least similar) result as the change in this pull request. What is your response to that?

Before developing this pull request, did you try using the --round-robin option to address the problem you were seeing?

If we make --round-robin the default, as @SpamapS has suggested, do we even need the changes in this PR? Will it make a difference?

[pythonerdog]

I think this code will not affect the current round-robin feature.

That wasn't my concern exactly, @pythonerdog. If I understand correctly, @SpamapS is saying that using the --round-robin option achieves the same (or at least similar) result as the change in this pull request. What is your response to that?

Before developing this pull request, did you try using the --round-robin option to address the problem you were seeing?

If we make --round-robin the default, as @SpamapS has suggested, do we even need the changes in this PR? Will it make a difference?

Got the point, yes we have already try --round-robin option when reproduce this priority issue. I can confirm that only enable --round-robin can't solve the issue in our business.

[esabol]

@pythonerdog wrote:

Got the point, yes we have already try --round-robin option when reproduce this priority issue. I can confirm that only enable --round-robin can't solve the issue in our business.

OK, good. Thank you for clarifying that point.

[pythonerdog]

@esabol may i ask what's the plan for next step or any other comment ?
Our business want to use the community gearmand purely. Thanks

[esabol]

@esabol may i ask what's the plan for next step or any other comment ? Our business want to use the community gearmand purely. Thanks

I'm still waiting on @SpamapS to review it.

[SpamapS]

And I hope to find time in the next few days. Work has been unusually busy the last few weeks.

…

On Tue, Nov 18, 2025, 12:43 AM Ed Sabol ***@***.***> wrote: *esabol* left a comment (gearman/gearmand#431) <#431 (comment)> @esabol <https://github.com/esabol> may i ask what's the plan for next step or any other comment ? Our business want to use the community gearmand purely. Thanks I'm still waiting on @SpamapS <https://github.com/SpamapS> to review it. — Reply to this email directly, view it on GitHub <#431 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADS6YDCDKYXQURPZNUBAMD35LL3TAVCNFSM6AAAAACKYCLM3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBWGIYTSNJXGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[SpamapS]

Hey so I am not entirely sure I understand the scenario in which things are breaking down for you, but the code looks OK. What's not OK is there's no test that validates the behavior. If we're going to change a behavior, I would like to be sure it works. Can you write a test for this?