You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[JENKINS-36547] Queue.Task.getFullDisplayName is a poor choice of key for LoadBalancer.CONSISTENT_HASH #17317
As mentioned parenthetically in the PR for JENKINS-48348, the implementation of getFullDisplayName may also be more expensive than we would want for calls from Queue.maintain. A dedicated method can be optimized to distinct constraints.
As mentioned parenthetically in the PR for JENKINS-48348, the implementation of getFullDisplayName may also be more expensive than we would want for calls from Queue.maintain. A dedicated method can be optimized to distinct constraints.
jglick: Thanks for mentioning. We can see in our instance allocating a node takes between 10 - 30s this may be caused by this. I'd like to give it a try - however I'm unsure how to improve the algorithm for speed. Should I open a separate ticket for this?
Maybe in a first step there could be the fix for the affinity and in the seconds step there could be a performance improvement.
jglick: Thanks for mentioning. We can see in our instance allocating a node takes between 10 - 30s this may be caused by this. I'd like to give it a try - however I'm unsure how to improve the algorithm for speed. Should I open a separate ticket for this?
Maybe in a first step there could be the fix for the affinity and in the seconds step there could be a performance improvement.
For backward compatibility of the jenkins core to older plugins I'd propose to do a default implementation of - let's say - getAffinityKey() in Queue.Task.
For backward compatibility of the jenkins core to older plugins I'd propose to do a default implementation of - let's say - getAffinityKey() in Queue.Task.
Activity
jenkins-infra-bot commentedon Jul 8, 2016
Remote links associated with this issue:
jenkins-infra-bot commentedon Sep 30, 2016
Raw content of original comment:
I'll throw in a +1 for this! We similarly had a "regression" switching to pipeline because of the lack of stable assignment.
jenkins-infra-bot commentedon May 29, 2017
Raw content of original comment:
Same issue here. Besides that our incremental builds suffer from poor locality because the pipeline always start on a different node then last time.
jenkins-infra-bot commentedon Jan 3, 2018
Raw content of original comment:
As mentioned parenthetically in the PR for
JENKINS-48348, the implementation of getFullDisplayName may also be more expensive than we would want for calls from Queue.maintain. A dedicated method can be optimized to distinct constraints.jenkins-infra-bot commentedon Jul 26, 2018
Raw content of original comment:
jglick: Thanks for mentioning. We can see in our instance allocating a node takes between 10 - 30s this may be caused by this. I'd like to give it a try - however I'm unsure how to improve the algorithm for speed. Should I open a separate ticket for this?
Maybe in a first step there could be the fix for the affinity and in the seconds step there could be a performance improvement.
jenkins-infra-bot commentedon Jul 26, 2018
Raw content of original comment:
For backward compatibility of the jenkins core to older plugins I'd propose to do a default implementation of - let's say - getAffinityKey() in Queue.Task.
jenkins-infra-bot commentedon Oct 9, 2018
Raw content of original comment:
Core part was released in Jenkins 2.145
jenkins-infra-bot commentedon Jan 14, 2019
Raw content of original comment:
PR against workflow-durable-task-step plugin: jenkinsci/workflow-durable-task-step-plugin#78
jenkins-infra-bot commentedon Jan 31, 2019
Raw content of original comment:
The Pipeline side of this was just released in version 2.29 of the Pipeline Nodes and Processes Plugin.