Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43936

Performance issues caused by User.getOrCreate

    XMLWordPrintable

Details

    Description

      According to the source code, when executing User.getOrCreate() this code is executed all the time even if the user is in memory. It only needs to be done once - which should be if the user is not in memory (ie do it once when the user is loaded) - after which it is in the map of loaded users - no need to do it again - ever.... (until Jenkins restart).

      One simple solution seems to be to change

      if (!configFile.isFile() && !configFile.getParentFile().isDirectory()) {
      

      per

      if (u == null && !configFile.isFile() && !configFile.getParentFile().isDirectory()) {
      

      The typical stacktrace I am seeing on Jenkins instance which reveal this is an issue is:

      "Handling GET /m2/securityRealm/finishLogin from X.X.X.X : RequestHandlerThread[#4449]" #326951 daemon prio=5 os_prio=0 tid=0x00007fb1f1480000 nid=0x2b0d runnable [0x00007fb1a3b2f000]
         java.lang.Thread.State: RUNNABLE
      	at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
      	at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
      	at java.io.File.isFile(File.java:882)
      	at hudson.model.User.getOrCreate(User.java:429)
      	at hudson.model.User.getById(User.java:529)
      	at hudson.model.User$UserIDCanonicalIdResolver.resolveCanonicalId(User.java:1071)
      	at hudson.model.User.get(User.java:399)
      	at hudson.model.User.get(User.java:368)
      	at hudson.model.User.get(User.java:488)
      

      For the moment, it seems to be only a problem on NFS systems with perhaps a non very good performance.

      Attachments

        Issue Links

          Activity

            fbelzunc Félix Belzunce Arcos created issue -
            fbelzunc Félix Belzunce Arcos made changes -
            Field Original Value New Value
            Status Open [ 1 ] In Progress [ 3 ]
            fbelzunc Félix Belzunce Arcos made changes -
            Description According to the source code, when executing User.getOrCreate() [this code|https://github.com/jenkinsci/jenkins/blob/1899f36bfc372ec9b2ee536d3630ea5246e4570f/core/src/main/java/hudson/model/User.java#L435-L462] is executed all the time even if the user is in memory. It only needs to be done once - which should be if the user is not in memory (ie do it once when the user is loaded) - after which it is in the map of loaded users - no need to do it again - ever.... (until Jenkins restart).

            One simple solution seems to be to change

            * https://github.com/jenkinsci/jenkins/blob/1899f36bfc372ec9b2ee536d3630ea5246e4570f/core/src/main/java/hudson/model/User.java#L435

            {code:java}
            if (!configFile.isFile() && !configFile.getParentFile().isDirectory()) {
            {code}

            per

            {code:java}
            if (u == null && !configFile.isFile() && !configFile.getParentFile().isDirectory()) {
            {code}
            According to the source code, when executing User.getOrCreate() [this code|https://github.com/jenkinsci/jenkins/blob/1899f36bfc372ec9b2ee536d3630ea5246e4570f/core/src/main/java/hudson/model/User.java#L435-L462] is executed all the time even if the user is in memory. It only needs to be done once - which should be if the user is not in memory (ie do it once when the user is loaded) - after which it is in the map of loaded users - no need to do it again - ever.... (until Jenkins restart).

            One simple solution seems to be to change

            * https://github.com/jenkinsci/jenkins/blob/1899f36bfc372ec9b2ee536d3630ea5246e4570f/core/src/main/java/hudson/model/User.java#L435

            {code:java}
            if (!configFile.isFile() && !configFile.getParentFile().isDirectory()) {
            {code}

            per

            {code:java}
            if (u == null && !configFile.isFile() && !configFile.getParentFile().isDirectory()) {
            {code}

            The typical stacktrace I am seeing on Jenkins instance which reveal this is an issue is:

            {code:java}
            "Handling GET /m2/securityRealm/finishLogin from 9.32.115.20 : RequestHandlerThread[#4449]" #326951 daemon prio=5 os_prio=0 tid=0x00007fb1f1480000 nid=0x2b0d runnable [0x00007fb1a3b2f000]
               java.lang.Thread.State: RUNNABLE
            at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
            at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
            at java.io.File.isFile(File.java:882)
            at hudson.model.User.getOrCreate(User.java:429)
            at hudson.model.User.getById(User.java:529)
            at hudson.model.User$UserIDCanonicalIdResolver.resolveCanonicalId(User.java:1071)
            at hudson.model.User.get(User.java:399)
            at hudson.model.User.get(User.java:368)
            at hudson.model.User.get(User.java:488)
            {code}

            For the moment, it seems to be only a problem on NFS systems with perhaps a non very good performance.

            fbelzunc Félix Belzunce Arcos made changes -
            Description According to the source code, when executing User.getOrCreate() [this code|https://github.com/jenkinsci/jenkins/blob/1899f36bfc372ec9b2ee536d3630ea5246e4570f/core/src/main/java/hudson/model/User.java#L435-L462] is executed all the time even if the user is in memory. It only needs to be done once - which should be if the user is not in memory (ie do it once when the user is loaded) - after which it is in the map of loaded users - no need to do it again - ever.... (until Jenkins restart).

            One simple solution seems to be to change

            * https://github.com/jenkinsci/jenkins/blob/1899f36bfc372ec9b2ee536d3630ea5246e4570f/core/src/main/java/hudson/model/User.java#L435

            {code:java}
            if (!configFile.isFile() && !configFile.getParentFile().isDirectory()) {
            {code}

            per

            {code:java}
            if (u == null && !configFile.isFile() && !configFile.getParentFile().isDirectory()) {
            {code}

            The typical stacktrace I am seeing on Jenkins instance which reveal this is an issue is:

            {code:java}
            "Handling GET /m2/securityRealm/finishLogin from 9.32.115.20 : RequestHandlerThread[#4449]" #326951 daemon prio=5 os_prio=0 tid=0x00007fb1f1480000 nid=0x2b0d runnable [0x00007fb1a3b2f000]
               java.lang.Thread.State: RUNNABLE
            at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
            at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
            at java.io.File.isFile(File.java:882)
            at hudson.model.User.getOrCreate(User.java:429)
            at hudson.model.User.getById(User.java:529)
            at hudson.model.User$UserIDCanonicalIdResolver.resolveCanonicalId(User.java:1071)
            at hudson.model.User.get(User.java:399)
            at hudson.model.User.get(User.java:368)
            at hudson.model.User.get(User.java:488)
            {code}

            For the moment, it seems to be only a problem on NFS systems with perhaps a non very good performance.

            According to the source code, when executing User.getOrCreate() [this code|https://github.com/jenkinsci/jenkins/blob/1899f36bfc372ec9b2ee536d3630ea5246e4570f/core/src/main/java/hudson/model/User.java#L435-L462] is executed all the time even if the user is in memory. It only needs to be done once - which should be if the user is not in memory (ie do it once when the user is loaded) - after which it is in the map of loaded users - no need to do it again - ever.... (until Jenkins restart).

            One simple solution seems to be to change

            * https://github.com/jenkinsci/jenkins/blob/1899f36bfc372ec9b2ee536d3630ea5246e4570f/core/src/main/java/hudson/model/User.java#L435

            {code:java}
            if (!configFile.isFile() && !configFile.getParentFile().isDirectory()) {
            {code}

            per

            {code:java}
            if (u == null && !configFile.isFile() && !configFile.getParentFile().isDirectory()) {
            {code}

            The typical stacktrace I am seeing on Jenkins instance which reveal this is an issue is:

            {code:java}
            "Handling GET /m2/securityRealm/finishLogin from X.X.X.X : RequestHandlerThread[#4449]" #326951 daemon prio=5 os_prio=0 tid=0x00007fb1f1480000 nid=0x2b0d runnable [0x00007fb1a3b2f000]
               java.lang.Thread.State: RUNNABLE
            at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
            at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
            at java.io.File.isFile(File.java:882)
            at hudson.model.User.getOrCreate(User.java:429)
            at hudson.model.User.getById(User.java:529)
            at hudson.model.User$UserIDCanonicalIdResolver.resolveCanonicalId(User.java:1071)
            at hudson.model.User.get(User.java:399)
            at hudson.model.User.get(User.java:368)
            at hudson.model.User.get(User.java:488)
            {code}

            For the moment, it seems to be only a problem on NFS systems with perhaps a non very good performance.

            scm_issue_link SCM/JIRA link daemon made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            oleg_nenashev Oleg Nenashev made changes -
            Labels lts-candidate
            olivergondza Oliver Gondža made changes -
            Labels lts-candidate 2.46.3-fixed
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-47429 [ JENKINS-47429 ]
            oleg_nenashev Oleg Nenashev made changes -
            Link This issue is related to JENKINS-47718 [ JENKINS-47718 ]

            People

              fbelzunc Félix Belzunce Arcos
              fbelzunc Félix Belzunce Arcos
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: