Recently I'm working on performance script which will test 3rd party service.
Test is very simple, each thread need to POST one request.
Number of Threads - 100,
Ramp Up - 680 s
While executing max number of active threads is 12.
I`m using Jmeter 3.2 version, but also tried on 2.1.
Unfortunately I'm obtaining java.net.SocketException: Connection reset error for 20-30% requests. Full error at the end of the post.
I`ve already change properties mentioned in many similar topics here (for example : I m getting java.net.SocketException: Connection reset exception while running a load test using Jmeter).
I've added:
httpclient4.retrycount=1
hc.parameters.file=hc.parameters
in user properties
http.socket.timeout$Integer=120000 (such big value is set just for test reasons ;) )
http.connection.stalecheck$Boolean=true in hc.parameters
httpclient.timeout=1200000
httpclient4.idletimeout=1200000 (same as previous) in jmeter.properties
I've also changed HTTP Request Sampler default values in Advanced tab to:
HTTPClient4 and both timeouts set to 120000.
Note: So big test timeouts are related to the time that some of request can take on service side (even 10 minutes).
Unfortunately after all those changes, I`m still getting this error and people responsible for the service, after analysis answered that it is nothing on their side.
Full error:
java.net.SocketException: Connection reset;
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.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:158);
at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:82;
at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:271);
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.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:281);
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:257);
at org.apache.jmeter.protocol.http.sampler.hc.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:199);
at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.receiveResponseHeader(MeasuringConnectionManager.java:212);
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.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:684);
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486);
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:835);
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83);
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:654);
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:413);
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74);
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1189);
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1178);
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:491);
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:425);
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:254);
at java.lang.Thread.run(Unknown Source);
First use JMeter 3.2 version.
Then try first manually the website, does it work correctly ?
If yes, run JMeter with 1 thread and check, if Connection Reset occur, then you most probably are not reproducing identically what browser does. In this case, record and try again.
If this only happens with many users, then your server is rejecting connection either due to an issue or a misconfiguration.
Related
Has anyone also noticed an issue with queue browsing with 5.16.2?
It happens when using an XA connection and starting a session without a transaction context.
This always worked fine but no longer does. Instead one can see a exception, but only when debug logging is turned on:
javax.jms.JMSException: Session's XAResource has not been enlisted in a distributed transaction.
at org.apache.activemq.ActiveMQXASession.doStartTransaction(ActiveMQXASession.java:101) ~[?:?]
This was changed a few years back in 5.16.0 via AMQ-2659. You need to set xaAckMode=1 on your URL now, e.g.:
tcp://localhost:61616?jms.xaAckMode=1
I am using JMeter 5.4.1, where I am using a HTTP request for Post API call. I am getting the error - "org.apache.http.ConnectionClosedException: Premature end of chunk coded message body: closing chunk expected".
Keep-Alive is checked.
Timeouts are also set to 60 Seconds.
I am getting this error after almost 30-45 Minutes when thread is started. I am using single thread.
What is the solution to get raid of this?
org.apache.http.ConnectionClosedException: Premature end of chunk coded message body: closing chunk expected
at org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:263)
at org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:222)
at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:183)
at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135)
at org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:148)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.readResponse(HTTPSamplerBase.java:1936)
at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.readResponse(HTTPAbstractImpl.java:476)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:673)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:66)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1296)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1285)
at org.apache.jmeter.threads.JMeterThread.doSampling(JMeterThread.java:638)
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:558)
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:489)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:256)
at java.lang.Thread.run(Unknown Source)
The error indicates that your server uses chunked Transfer-Encoding and doesn't provide last-chunk
Most probably you're getting an incomplete response therefore JMeter reports this error.
My expectation is that your server gets overloaded therefore it cannot properly respond to JMeter's requests so there is nothing you "get raid" of from JMeter perspective, the issue needs to be fixed on the server side.
Check your server logs
Make sure that the server has enough headroom to operate in terms of CPU, RAM, etc., it can be done using JMeter PerfMon Plugin
Enable debug logging for JMeter's HTTP components by adding the next line to log4j2.xml file:
<Logger name="org.apache.http" level="debug" />
this way you will be able to see full request/response details in the jmeter.log file and it should allow you to get to the bottom of the issue.
I'm new on Open Liberty and I need to maintain a legacy app
I have on this app logs the following error:
The ConnectionManager was unable to associate Connection com.ibm.ws.rsadapter.jdbc.WSJdbcConnection#3b05f444 with ManagedConnection
WSRdbManagedConnectionImpl#67538473 for resource jdbc/AppDs. Received exception: com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException:
DSRA9420E: Connection cannot be reassociated because child objects are still open.
I'm not sure from to start on this.
I have already searched here
But the code that is shown on logs is based on spring and it couldn't leak connections.
The app uses spring and ehcache.
Please, can someone to provide some guidance?
Looking at the Open Liberty source, that error is raised from a single place in the code, in response to the error condition that a JDBC Connection still has open child JDBC resources (such as Statement, PreparedStatement, ...) associated with it, at a point where it is being asked to reassociate the connection handle across transaction boundaries. Looking at the single caller of that code, it appears that the dissociate method (which closes these same JDBC resources) would have been invoked only a few lines earlier, suggesting that the only way for you to reach the state where the error occurs is if other code were simultaneously using the connection from another thread. To help confirm if this is the case, you could try enabling Liberty trace (via server.xml config) of
<logging traceSpecification="*=info:RRA=all"/>
while reproducing the error and post it somewhere accessible to look at.
While testing Blazemeter Parallel Controller (0.9) with Jmeter 5.3 version with multiple https requests in the parallel controller, we are getting the following exception -
java.net.SocketException: Socket Closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
....
I identified that it is passing for only one of the http samplers in the parallel controller. I modified various parameters like ssl socket protocol, or connect timeouts in 5.3 but to no avail.
We tried the same script on JMeter 5.2.1 or lower versions and it works without any changes/issues.Also, if I change the parallel controller to transaction controller in JMeter 5.3, it is starting to work without issues - ruling out any script issues.
It seems to have some issue with newer version of JMeter vs BZM Parallel Controller
(0.9) or I may be missing any new setting to be done on JMeter 5.3 to make this work.
As of now we were running on 5.2.1 to avoid the above scenario exception but seems now, we need to move to JMeter 5.3 as part of our Organization SW upgrade and need to get a workaround for the same.
Could you please help if you have faced this and found any workaround for the same?
Had the same problem on my side with bzm - I wanted to perform in one thread group 1 login, parallel execution of send & receive messages, and 1 logout. Everything worked well except the socket closed exception on one parallel thread whenever the other one ended its job.
I ended up removing the parallel controller.
I instead went to using a combination of setup and tear-down thread groups to login and logout, and worked out the cross thread-group variable sharing problems by going through JMeter properties initialization with beanshell assertion (good article on how to that here : https://medium.com/#priyank.it/jmeter-passing-variables-between-threads-a4dc09903b59).
That worked for my use case, but it might not for yours.
Am testing with an realtime application upto 40 users everything going fine after 40 users if i increased users to 45 or 50 and so on getting java.net.socketexception:connection reset errors could you please suggest a solution for this?
Most probably it indicates an issue with your application, check if there are any suspicious entries which can shed light on the root cause in your application logs. It might also be a configuration issue of any middleware (load balancers, routers, switches, proxies, etc.)
If you absolutely sure that your application behaves as expected you can tune JMeter to do retries on connection resets (however this will make your test not realistic from browser perspective), in order to do this:
In user.properties file add the next lines:
httpclient4.retrycount=1
hc.parameters.file=hc.parameters
In hc.parameters add the next line:
http.connection.stalecheck$Boolean=true
Restart JMeter to pick up the changes.
References:
Connection Reset since JMeter 2.10 ?
Configuring JMeter
JMeter Properties Reference
Apache JMeter Properties Customization Guide