[JENKINS-47725] Peformance issue at java.util.WeakHashMap.put(WeakHashMap.java:453)

Type: Bug
Resolution: Fixed
Priority: Minor
Component/s: workflow-api-plugin
Labels:
None

Similar Issues:
Powered by SuggestiMate

Show
URL:
https://github.com/jenkinsci/workflow-api-plugin/pull/58

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)

links to

CloudBees Internal CD-335

Félix Belzunce Arcos created issue - 2017-10-30 07:24

Félix Belzunce Arcos made changes - 2017-10-30 07:25

Description

Original: 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}

New: 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}

Félix Belzunce Arcos made changes - 2017-10-30 07:27

Status

Original: Open [ 1 ]

New: In Progress [ 3 ]

Félix Belzunce Arcos made changes - 2017-10-30 07:37

URL

New: https://github.com/jenkinsci/workflow-api-plugin/pull/58

Jesse Glick made changes - 2017-10-30 12:58

Description

Original: 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}

New: 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}

Jesse Glick made changes - 2017-10-30 12:58

Status

Original: In Progress [ 3 ]

New: In Review [ 10005 ]

James Dumay made changes - 2017-12-04 05:55

Resolution		New: Fixed [ 1 ]
Status	Original: In Review [ 10005 ]	New: Resolved [ 5 ]

CloudBees Inc. made changes - 2017-12-05 06:19

Remote Link

New: This issue links to "CloudBees Internal CD-335 (Web Link)" [ 18951 ]

Assignee:: Félix Belzunce Arcos

Reporter:: Félix Belzunce Arcos

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Created:: 2017-10-30 07:24

Updated:: 2017-12-05 06:19

Resolved:: 2017-12-04 05:55

Jenkins

Details

Description

Attachments

Issue Links

Activity

People

Dates