-
Bug
-
Resolution: Fixed
-
Minor
-
None
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
