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

Peformance issue at java.util.WeakHashMap.put(WeakHashMap.java:453)

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I have recently see in an instance the following stacktrace repeated several times and consuming a full core of a processor. This indicates something wrong in either the plugin or directly in the Java implementation of java.util.WeakHashMap.put

      Doing a little bit of research found http://adambien.blog/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap , which indicates we should synchronize the access to WeakHashMap should be synchornized.

      As per https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html 

      Like most collection classes, this class is not synchronized. A synchronized WeakHashMap may be constructed using the Collections.synchronizedMap method.
      
      • Stacktrace
      "SSHLauncher.launch for '<MY_NODE>' node [#1]" #360017 prio=5 os_prio=0 tid=0x00007f91bc204000 nid=0x1cd20 runnable [0x00007f90bbd0c000]
         java.lang.Thread.State: RUNNABLE
          at java.util.WeakHashMap.put(WeakHashMap.java:453)
          at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.addChannel(FilePathUtils.java:158)
          at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.preOnline(FilePathUtils.java:147)
          at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:540)
          at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381)
          at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:979)
          at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:139)
          at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:728)
          at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:709)
          at java.util.concurrent.FutureTask.run(FutureTask.java:266)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
          at java.lang.Thread.run(Thread.java:745)
      
         Locked ownable synchronizers:
          - <0x00000003e64323a8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
      

       

        Attachments

          Issue Links

            Activity

            fbelzunc Félix Belzunce Arcos created issue -
            fbelzunc Félix Belzunce Arcos made changes -
            Field Original Value New Value
            Description I have recently see in an instance the following stacktrace repeated several times and consuming a full core of a processor. This indicates something wrong in either the plugin or directly in the Java implementation of \{\{{{java.util.WeakHashMap.put}}.}}

             

            Doing a little bit of research found [http://adambien.blog/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap] , which indicates we should synchronize the access to {{WeakHashMap}} should be synchornized.

            As per [https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html

             
            {noformat}
            Like most collection classes, this class is not synchronized. A synchronized WeakHashMap may be constructed using the Collections.synchronizedMap method.
            {noformat}
             

            # Stacktrace

             

             
            {code:java}
            "SSHLauncher.launch for '<MY_NODE>' node [#1]" #360017 prio=5 os_prio=0 tid=0x00007f91bc204000 nid=0x1cd20 runnable [0x00007f90bbd0c000]
               java.lang.Thread.State: RUNNABLE
                at java.util.WeakHashMap.put(WeakHashMap.java:453)
                at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.addChannel(FilePathUtils.java:158)
                at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.preOnline(FilePathUtils.java:147)
                at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:540)
                at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381)
                at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:979)
                at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:139)
                at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:728)
                at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:709)
                at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
                at java.lang.Thread.run(Thread.java:745)

               Locked ownable synchronizers:
                - <0x00000003e64323a8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
            {code}
             
            I have recently see in an instance the following stacktrace repeated several times and consuming a full core of a processor. This indicates something wrong in either the plugin or directly in the Java implementation of \{\{{{java.util.WeakHashMap.put}}.}}

             

            Doing a little bit of research found [http://adambien.blog/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap] , which indicates we should synchronize the access to {{WeakHashMap}} should be synchornized.

            As per [https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html
            {noformat}
            Like most collection classes, this class is not synchronized. A synchronized WeakHashMap may be constructed using the Collections.synchronizedMap method.
            {noformat}
             * Stacktrace

            {code:java}
            "SSHLauncher.launch for '<MY_NODE>' node [#1]" #360017 prio=5 os_prio=0 tid=0x00007f91bc204000 nid=0x1cd20 runnable [0x00007f90bbd0c000]
               java.lang.Thread.State: RUNNABLE
                at java.util.WeakHashMap.put(WeakHashMap.java:453)
                at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.addChannel(FilePathUtils.java:158)
                at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.preOnline(FilePathUtils.java:147)
                at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:540)
                at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381)
                at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:979)
                at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:139)
                at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:728)
                at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:709)
                at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
                at java.lang.Thread.run(Thread.java:745)

               Locked ownable synchronizers:
                - <0x00000003e64323a8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
            {code}
             
            fbelzunc Félix Belzunce Arcos made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            jglick Jesse Glick made changes -
            Description I have recently see in an instance the following stacktrace repeated several times and consuming a full core of a processor. This indicates something wrong in either the plugin or directly in the Java implementation of \{\{{{java.util.WeakHashMap.put}}.}}

             

            Doing a little bit of research found [http://adambien.blog/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap] , which indicates we should synchronize the access to {{WeakHashMap}} should be synchornized.

            As per [https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html
            {noformat}
            Like most collection classes, this class is not synchronized. A synchronized WeakHashMap may be constructed using the Collections.synchronizedMap method.
            {noformat}
             * Stacktrace

            {code:java}
            "SSHLauncher.launch for '<MY_NODE>' node [#1]" #360017 prio=5 os_prio=0 tid=0x00007f91bc204000 nid=0x1cd20 runnable [0x00007f90bbd0c000]
               java.lang.Thread.State: RUNNABLE
                at java.util.WeakHashMap.put(WeakHashMap.java:453)
                at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.addChannel(FilePathUtils.java:158)
                at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.preOnline(FilePathUtils.java:147)
                at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:540)
                at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381)
                at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:979)
                at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:139)
                at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:728)
                at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:709)
                at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
                at java.lang.Thread.run(Thread.java:745)

               Locked ownable synchronizers:
                - <0x00000003e64323a8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
            {code}
             
            I have recently see in an instance the following stacktrace repeated several times and consuming a full core of a processor. This indicates something wrong in either the plugin or directly in the Java implementation of {{java.util.WeakHashMap.put}}. 

            Doing a little bit of research found [http://adambien.blog/roller/abien/entry/endless_loops_in_unsychronized_weakhashmap] , which indicates we should synchronize the access to {{WeakHashMap}} should be synchornized.

            As per [https://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html
            {noformat}
            Like most collection classes, this class is not synchronized. A synchronized WeakHashMap may be constructed using the Collections.synchronizedMap method.
            {noformat}
             * Stacktrace

            {code:java}
            "SSHLauncher.launch for '<MY_NODE>' node [#1]" #360017 prio=5 os_prio=0 tid=0x00007f91bc204000 nid=0x1cd20 runnable [0x00007f90bbd0c000]
               java.lang.Thread.State: RUNNABLE
                at java.util.WeakHashMap.put(WeakHashMap.java:453)
                at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.addChannel(FilePathUtils.java:158)
                at org.jenkinsci.plugins.workflow.FilePathUtils$Listener.preOnline(FilePathUtils.java:147)
                at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:540)
                at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381)
                at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:979)
                at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:139)
                at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:728)
                at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:709)
                at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
                at java.lang.Thread.run(Thread.java:745)

               Locked ownable synchronizers:
                - <0x00000003e64323a8> (a java.util.concurrent.ThreadPoolExecutor$Worker)
            {code}
             
            jglick Jesse Glick made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            jamesdumay James Dumay made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal CD-335 (Web Link)" [ 18951 ]

              People

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

                Dates

                Created:
                Updated:
                Resolved: