support-core analysis of slow requests turned up a case where rendering changelog information for a (Pipeline) job was consuming a lot of time with stack traces such as

      java.lang.String$CaseInsensitiveComparator.compare(String.java:1186)
      java.lang.String.compareToIgnoreCase(String.java:1239)
      hudson.util.CaseInsensitiveComparator.compare(CaseInsensitiveComparator.java:40)
      hudson.util.CaseInsensitiveComparator.compare(CaseInsensitiveComparator.java:34)
      jenkins.model.IdStrategy$CaseInsensitive.compare(IdStrategy.java:174)
      jenkins.model.IdStrategy.equals(IdStrategy.java:89)
      nectar.plugins.rbac.groups.Group.isMatch(Group.java:473)
      nectar.plugins.rbac.groups.Group.isMatch(Group.java:425)
      nectar.plugins.rbac.groups.Group.isMatch(Group.java:362)
      nectar.plugins.rbac.groups.GroupContainerACL.hasPermission(GroupContainerACL.java:157)
      nectar.plugins.rbac.groups.GroupContainerACL._hasPermission(GroupContainerACL.java:106)
      nectar.plugins.rbac.groups.GroupContainerACL.hasPermission(GroupContainerACL.java:72)
      hudson.security.ACL.hasPermission(ACL.java:73)
      hudson.model.AbstractItem.hasPermission(AbstractItem.java:505)
      com.cloudbees.hudson.plugins.folder.AbstractFolder.getItems(AbstractFolder.java:568)
      hudson.model.Items.getAllItems(Items.java:357)
      hudson.model.Items.getAllItems(Items.java:377)
      hudson.model.Items.getAllItems(Items.java:377)
      hudson.model.Items.getAllItems(Items.java:377)
      hudson.model.Items.getAllItems(Items.java:353)
      jenkins.model.Jenkins.getAllItems(Jenkins.java:1409)
      hudson.scm.AutoBrowserHolder.infer(AutoBrowserHolder.java:77)
      hudson.scm.AutoBrowserHolder.get(AutoBrowserHolder.java:64)
      hudson.scm.SCM.getEffectiveBrowser(SCM.java:136)
      org.jenkinsci.plugins.workflow.job.WorkflowRun.getChangeSets(WorkflowRun.java:612)
      com.cloudbees.workflow.rest.external.ChangeSetExt.hasChanges(ChangeSetExt.java:139)
      com.cloudbees.workflow.rest.external.RunExt.createOld(RunExt.java:324)
      com.cloudbees.workflow.rest.external.RunExt.create(RunExt.java:303)
      com.cloudbees.workflow.rest.external.JobExt.create(JobExt.java:126)
      com.cloudbees.workflow.rest.endpoints.JobAPI.doRuns(JobAPI.java:68)
      

      The top of the stack is specific to a proprietary AuthorizationStrategy, and the bottom is specific to pipeline-stage-view, but the middle clearly shows that SCM.getEffectiveBrowser is potentially rather expensive: if no RepositoryBrowser has been explicitly configured, and guessBrowser does not offer a default, then Jenkins will search all projects in the system (not including Pipeline) for similar SCM configurations which might let it infer the browser. The performance problem lies in the fact that a permission check must be done on each candidate project, lest a user of one job gain access to a secret SCM browser configuration from a job he would not otherwise be able to see (or even know of the existence of).

      This is an especially dubious feature in light of the fact that among all the OSS SCM plugins, there seem to be only two which actually implement isBrowserReusable: subversion; and cvs, which actually does so incorrectly (would produce bogus matches). So if for example you only use Git in your Jenkins installation, all this computation will be wasted.

      I propose to just delete this feature and deprecate the associated APIs. The more recently introduced guessBrowser is a more appropriate way to reduce the configuration burden for users of public hosting services. For users of private repositories, where guessBrowser is unlikely to work (depends on the SCM), various job templating systems are a more straightforward and predictable way of reducing repetition in Jenkins configuration.

      If there is someone who really finds this feature valuable, I think it would best be done as a plugin which explicitly offers to configure your repository browser on various jobs based on known examples; and/or there could be an extension point allowing for third-party contributions to guessBrowser. Either way, isBrowserReusable is not really needed for such features anyway; getKey (introduced alongside guessBrowser) is already more widely implemented and can be used for essentially the same purpose.

          [JENKINS-35098] Poor performance of AutoBrowserHolder

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/java/hudson/scm/AutoBrowserHolder.java
          core/src/main/java/hudson/scm/NullSCM.java
          core/src/main/java/hudson/scm/SCM.java
          core/src/main/java/hudson/scm/SCMDescriptor.java
          core/src/main/java/hudson/scm/SCMS.java
          core/src/main/resources/lib/hudson/project/config-scm.jelly
          http://jenkins-ci.org/commit/jenkins/d33df0f2e4cbe5a6e35f34ece96059826aa7471d
          Log:
          JENKINS-35098 Disable AutoBrowserHolder by default to improve the changelog rendering performance (#2371)

          • [FIXED JENKINS-35098] Deleting AutoBrowserHolder.
          • Normalizing form binding scheme for AbstractProject.scm.
          • At @oleg-nenashev’s insistence, restoring AutoBrowserHolder, though not using it by default.
          • Using SystemProperties at @oleg-nenashev’s recommendation.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/java/hudson/scm/AutoBrowserHolder.java core/src/main/java/hudson/scm/NullSCM.java core/src/main/java/hudson/scm/SCM.java core/src/main/java/hudson/scm/SCMDescriptor.java core/src/main/java/hudson/scm/SCMS.java core/src/main/resources/lib/hudson/project/config-scm.jelly http://jenkins-ci.org/commit/jenkins/d33df0f2e4cbe5a6e35f34ece96059826aa7471d Log: JENKINS-35098 Disable AutoBrowserHolder by default to improve the changelog rendering performance (#2371) [FIXED JENKINS-35098] Deleting AutoBrowserHolder. Normalizing form binding scheme for AbstractProject.scm. At @oleg-nenashev’s insistence, restoring AutoBrowserHolder, though not using it by default. Using SystemProperties at @oleg-nenashev’s recommendation.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java
          http://jenkins-ci.org/commit/workflow-job-plugin/70ec663adff70fb17a97c77bdea4a3ea081cd0ec
          Log:
          JENKINS-35098 Work around core misfeature when using 1.642.x or 1.651.x.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java http://jenkins-ci.org/commit/workflow-job-plugin/70ec663adff70fb17a97c77bdea4a3ea081cd0ec Log: JENKINS-35098 Work around core misfeature when using 1.642.x or 1.651.x.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java
          http://jenkins-ci.org/commit/workflow-job-plugin/7ef365b3c4709be370caf1ac32f242472cf2705b
          Log:
          Merge pull request #30 from jglick/getEffectiveBrowser-JENKINS-35098

          JENKINS-35098 Work around core misfeature when using 1.642.x or 1.651.x

          Compare: https://github.com/jenkinsci/workflow-job-plugin/compare/d074acbe8b2d...7ef365b3c470

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/org/jenkinsci/plugins/workflow/job/WorkflowRun.java http://jenkins-ci.org/commit/workflow-job-plugin/7ef365b3c4709be370caf1ac32f242472cf2705b Log: Merge pull request #30 from jglick/getEffectiveBrowser- JENKINS-35098 JENKINS-35098 Work around core misfeature when using 1.642.x or 1.651.x Compare: https://github.com/jenkinsci/workflow-job-plugin/compare/d074acbe8b2d...7ef365b3c470

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: