java.net.SocketException: Socket closed at the end of the script duration when using Jmeter Concurrency Thread Group

Question

I am using Jmeter 5.2.1 along with Concurrency Thread Group with ${__tstFeedback(ThroughputShapingTimer,1,10,10)} in combination with the Throughput Shaping Timer to dynamically change the target throughput throughout the test duration.

The Test Plan consists of a Thread group having a Module Controller and the ThroughputShapingTimer underneath it. The module controller controls a Test Fragment which contains the test logic.

I am encountering an issue at the end of the test where most of the time, a few last samplers result in a "java.net.SocketException: Socket closed" exception. This happens regardless if I have a ramp-down to 0 at the end of the test or not.

By contrast, if I use the same script with the same setup but just control it from a normal Thread Group, then all of the samplers complete successfully at the end of the script without issues.

Here are some screenshots of my setup:

Full error text from the sampler:

java.net.SocketException: Socket closed
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.socketRead(Unknown Source)
    at java.net.SocketInputStream.read(Unknown Source)
    at java.net.SocketInputStream.read(Unknown Source)
    at sun.security.ssl.InputRecord.readFully(Unknown Source)
    at sun.security.ssl.InputRecord.read(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
    at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
    at sun.security.ssl.AppInputStream.read(Unknown Source)
    at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
    at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
    at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280)
    at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
    at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
    at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
    at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
    at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
    at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
    at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
    at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:850)
    at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:561)
    at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:67)
    at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1282)
    at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1271)
    at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:627)
    at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:551)
    at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:490)
    at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
    at java.lang.Thread.run(Unknown Source)

I would like to understand what the cause could be as this is impacting the reporting.

Any help to remove or work around this issue would be very appreciated.

Answer 1

JMeter cannot gracefully terminate the thread after 5 tries hence it forcefully terminates the connection, in your case this termination happens during response from the server breaking SSL tunnel and causing the error.

"Normal" thread group uses different approach for stopping the threads which cannot be re-used in the Concurrency Thread Group as in your case it spawns an extra pool of threads which doesn't belong to the Thread Group unless they're explicitly used hence they're kind of beyond JMeter's control.

If you still want to use the Concurrency Thread Group and just want to ignore or filter out the error it can be done using:

1. JMeter Plugins Command Line Tool Plugin
2. Filter Results Plugin
3. Response Assertion and "Ignore Status" box
4. JSR223 Assertion and your custom code to conditionally mark the sampler(s) in scope as passed or failed