[JENKINS-61439] Many branches on a multibranch repo are slowed by cache lock on master

On our project we have a large number of feature builds across several versions that run as separate builds on Jenkins. We have noticed that our multibranch builds for this have been creeping up in run times, with no immediately obvious cause in the code changes, and after some digging, it seems that even though each build is running independently, there is a singular lock for each unique remote name that each git process waits to acquire. Even though each fetch and checkout is relatively fast, this seems to lead to a huge backlog of builds in contention over the lock as the multibranch pipeline starts each build on dev before requisitioning a slave and executing the specific tasks needed.

I have been digging and not found anyone who seems to have hit the same issue so it is likely that we have some unusual setup that doesn't match with standard usage, but it also seems strange that we are locking on the remote name rather than the directory (which is more likely to have synchronisation issues).

The specific bit of the plugin that is acquiring the lock seems to be AbstractGitSCMSource.getCacheLock(). I've attached a thread dump illustrating the various threads all stacked up on the singular lock.

---
Originally reported by mellams, imported from: Many branches on a multibranch repo are slowed by cache lock on master

• status: Open
  
• priority: Major
  
• component(s): git-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 2
  
• imported: 2025-12-02
  

Raw content of original issue

On our project we have a large number of feature builds across several versions that run as separate builds on Jenkins. We have noticed that our multibranch builds for this have been creeping up in run times, with no immediately obvious cause in the code changes, and after some digging, it seems that even though each build is running independently, there is a singular lock for each unique remote name that each git process waits to acquire. Even though each fetch and checkout is relatively fast, this seems to lead to a huge backlog of builds in contention over the lock as the multibranch pipeline starts each build on dev before requisitioning a slave and executing the specific tasks needed.


I have been digging and not found anyone who seems to have hit the same issue so it is likely that we have some unusual setup that doesn't match with standard usage, but it also seems strange that we are locking on the remote name rather than the directory (which is more likely to have synchronisation issues).


The specific bit of the plugin that is acquiring the lock seems to be AbstractGitSCMSource.getCacheLock(). I've attached a thread dump illustrating the various threads all stacked up on the singular lock.

1 attachment

- [threaddump.txt](https://issues.jenkins.io/secure/attachment/50649/threaddump.txt)