You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running in non-GUI mode with a few hundred monitoring instances (each with a single sampler row / command), threads get stuck when JMeter tries to shutdown the JVM (irrespective of increasing the jmeter.exit.check.pause) with log output like the following:
... end of run
The JVM should have exited but did not.
The following non-daemon threads are still running (DestroyJavaVM is OK):
Thread[Thread-430,5,main], stackTrace:java.lang.Object#wait
java.io.PipedInputStream#read
java.io.PipedInputStream#read
sun.nio.cs.StreamDecoder#readBytes
sun.nio.cs.StreamDecoder#implRead
sun.nio.cs.StreamDecoder#read
java.io.InputStreamReader#read
java.io.Reader#read
org.apache.commons.io.IOUtils#copyLarge at line:2537
org.apache.commons.io.IOUtils#copyLarge at line:2516
org.apache.commons.io.IOUtils#copy at line:2493
org.apache.commons.io.IOUtils#copy at line:2441
org.apache.commons.io.IOUtils#toString at line:1084
org.apache.commons.io.IOUtils#toString at line:1064
nz.co.breakpoint.jmeter.vizualizers.sshmon.SSHMonSampler#generateSamples at line:65
kg.apc.jmeter.vizualizers.MonitoringResultsCollector#processConnectors at line:215
kg.apc.jmeter.vizualizers.MonitoringResultsCollector#run at line:122
java.lang.Thread#run
A thread dump shows locked InputStreams, which suggests the Channel is still busy reading command output:
"Thread-430" #422 prio=5 os_prio=0 tid=0x00007f3b50388800 nid=0x504b in Object.wait() [0x00007f3b328aa000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.io.PipedInputStream.read(Unknown Source)
- locked <0x00000000c1e94458> (a com.jcraft.jsch.Channel$MyPipedInputStream)
at java.io.PipedInputStream.read(Unknown Source)
- locked <0x00000000c1e94458> (a com.jcraft.jsch.Channel$MyPipedInputStream)
at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
at sun.nio.cs.StreamDecoder.read(Unknown Source)
- locked <0x00000000c1e964f8> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(Unknown Source)
at java.io.Reader.read(Unknown Source)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2537)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2516)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:2493)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:2441)
at org.apache.commons.io.IOUtils.toString(IOUtils.java:1084)
at org.apache.commons.io.IOUtils.toString(IOUtils.java:1064)
at nz.co.breakpoint.jmeter.vizualizers.sshmon.SSHMonSampler.generateSamples(SSHMonSampler.java:65)
at kg.apc.jmeter.vizualizers.MonitoringResultsCollector.processConnectors(MonitoringResultsCollector.java:215)
at kg.apc.jmeter.vizualizers.MonitoringResultsCollector.run(MonitoringResultsCollector.java:122)
- locked <0x00000000c015b010> (a nz.co.breakpoint.jmeter.vizualizers.sshmon.SSHMonCollector)
at java.lang.Thread.run(Unknown Source)
The text was updated successfully, but these errors were encountered:
When running in non-GUI mode with a few hundred monitoring instances (each with a single sampler row / command), threads get stuck when JMeter tries to shutdown the JVM (irrespective of increasing the
jmeter.exit.check.pause
) with log output like the following:A thread dump shows locked InputStreams, which suggests the Channel is still busy reading command output:
The text was updated successfully, but these errors were encountered: