Why connection timed out when recording in Jmeter? - jmeter

I was recording script in Jmeter and got error like this:
There is a problem with this website's security certificate
then I click Continue to this website (not recommended)
and got connection timed out like this:
java.net.ConnectException: Connection timed out: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) at java.net.
Please help.
UPDATED
I should run jmeter using proxy due to proxy enabled in my area.
After running using proxy, I found new error SAML Authentication (https://www.blazemeter.com/blog/how-load-test-saml-sso-secured-websites)

Ensure you add the JMeter Certificate Authority to your browser following this documentation:
http://jmeter.apache.org/usermanual/component_reference.html#HTTP(S)_Test_Script_Recorder
Installing the JMeter CA certificate for HTTPS recording
This file is generated in "jmeter/bin/ApacheJMeterTemporaryRootCA.crt" when your start the recorder.

Related

JMeter javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake Load testing

I am trying to test my API using Jmeter Load testing and i am encountering this error whenever i tried to test 10 or more concurrent request in 20 seconds or more:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
at org.apache.jmeter.protocol.http.sampler.hc.LazyLayeredConnectionSocketFactory.connectSocket(LazyLayeredConnectionSocketFactory.java:92)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$JMeterDefaultHttpClientConnectionOperator.connect(HTTPHC4Impl.java:326)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:374)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
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)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(Unknown Source)
... 27 more
10 concurrent user for 10 seconds is successful but when i up my testing, some request replied the above error and some request had been successful during the testing. I think this is not a code issue anymore. In this regard, May i know what is the problem for this? I am trying to test my API from my workstation(Windows) to Linux Dev server where the API is located and i am curious why only some request replied with this error while some is successful since my API URL uses HTTPS.
If you're getting this SSL peer shut down incorrectly error only under the load most probably it means that your system under test gets overloaded and cannot properly respond/gracefully end the connection.
Check your system under test logs for any suspicious entries
Make sure that the system under test has enough headroom to operate in terms of CPU, RAM, Network, etc, it can be done using JMeter PerfMon Plugin
From JMeter side of things you can:
Make sure to follow JMeter Best Practices
The same as for the system under test - make sure that JMeter doesn't lack underlying operating system resources, if it does - consider running JMeter in distributed mode
You can also add javax.net.debug=all line to system.properties file, this way you will get way more information regarding underlying connections problems in stdout
In addition you can add the next lines to log4j2.xml file, this way you will see more details on network connections level in the jmeter.log file
<Logger name="org.apache.http" level="debug" />
<Logger name="org.apache.http.wire" level="debug"/>

Jmeter - Non HTTP response code: org.apache.http.conn.HttpHostConnectException is observed on trying to record a script for 1 user

I am trying to record a login scenario for my application built using Blazor technology through Templates (File > Templates > Recording) for a single user.
I see that few of the initial sampler results are successful and then I see the below error in View Results Tree. Error is constant on trying many times.
Sampler Result
Thread Name:
Sample Start:2021-01-12 09:35:17 GMT
Load time:21037
Connect Time:21037
Latency:0
Size in bytes:2582
Sent bytes:0
Headers size in bytes:0
Body size in bytes:2582
Sample Count:1
Error Count:1
Data type ("text"|"bin"|""):text
Response code:Non HTTP response code: org.apache.http.conn.HttpHostConnectException
Response message:Non HTTP response message: Connect to push.services.mozilla.com:443 [push.services.mozilla.com/44.238.116.130] failed: Connection timed out: connect
HTTPSampleResult fields:
ContentType:
DataEncoding: null
Response Data:
org.apache.http.conn.HttpHostConnectException: Connect to push.services.mozilla.com:443 [push.services.mozilla.com/44.238.116.130] failed: Connection timed out: connect
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$JMeterDefaultHttpClientConnectionOperator.connect(HTTPHC4Impl.java:401)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
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:930)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:641)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:66)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1281)
at org.apache.jmeter.protocol.http.proxy.Proxy.run(Proxy.java:234)
Caused by: java.net.ConnectException: Connection timed out: connect
at java.base/java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.base/java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.base/java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.base/java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.base/java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.base/java.net.PlainSocketImpl.connect(Unknown Source)
at java.base/java.net.SocksSocketImpl.connect(Unknown Source)
at java.base/java.net.Socket.connect(Unknown Source)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368)
at org.apache.jmeter.protocol.http.sampler.hc.LazyLayeredConnectionSocketFactory.connectSocket(LazyLayeredConnectionSocketFactory.java:91)
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
... 14 more
In the logs, I see errror in
Line 2: 2021-01-12 09:34:16,562 ERROR f.configuration: DefaultObjectWrapper.incompatibleImprovements was set to the object returned by Configuration.getVersion(). That defeats the purpose of incompatibleImprovements, and makes upgrading FreeMarker a potentially breaking change. Also, this probably won't be allowed starting from 2.4.0. Instead, set incompatibleImprovements to the highest concrete version that's known to be compatible with your application.
Line 3: 2021-01-12 09:34:16,562 ERROR f.configuration: Configuration.incompatibleImprovements was set to the object returned by Configuration.getVersion(). That defeats the purpose of incompatibleImprovements, and makes upgrading FreeMarker a potentially breaking change. Also, this probably won't be allowed starting from 2.4.0. Instead, set incompatibleImprovements to the highest concrete version that's known to be compatible with your application.
Line 72: 2021-01-12 09:37:39,166 WARN o.a.j.p.h.p.Proxy: [53022] Problem with SSL certificate for url for 'incoming.telemetry.mozilla.org'? Ensure browser is set to accept the JMeter proxy cert: Software caused connection abort: recv failed
NOTE :
I have tried recording using the Non HTTP Script Recorder too - same issue.
I see this issue when application is launched on a test server with no internet connection.
I see this issue when the application is hosted locally on the same test server.
Also in UI - Page contents do not load and login page is displayed as a blank page with only the page title and page url as expected.
The application URL is of the format https://abcd.com:1234/login
I have updated the port number in JMeter and Firefox browser as 8888
Root CA certificate is added.
I see the same issue even after increasing timeout to 60000 in HTTP Request defaults
Looking into the push.services.mozilla.com hostname it appears that JMeter catches requests to Firefox Web Push notifications service (allowing websites to send notifications to you)
I don't think you should be recording these requests (unless you're explicitly testing them) so you should add this push.services.mozilla.com to "URL Patterns to Exclude" section of the HTTP(S) Test Script Recorder
More information: Excluding Domains from the Load Test
You should repeat the exercise for all the requests to/from 3rd-party domains if any so your test scope would be limited to your system under test only

JMeter Script- Connection timed out

I am receiving the below error when trying to run a JMeter script . The API works fine in Loadrunner .
I had set the https.default.protocol=TLSv1.2 in user.properties for the SSL version. What could cause the below error .
org.apache.http.conn.HttpHostConnectException: Connect to rXXXXX.XXXX-XXXX.XXXXXX.net:443 [XXXXXX.XXXXXX-XXXXXX.XXXXXX.XXXXXX/21.60.245.182] failed: Connection timed out: connect
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:156)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl$JMeterDefaultHttpClientConnectionOperator.connect(HTTPHC4Impl.java:326)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:374)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
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.threads.JMeterThread.run(JMeterThread.java:257)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.ConnectException: Connection timed out: connect
e
Given you send the same request you should get the same response no matter what tool is being used for sending the request.
If you're getting different responses or not getting a response either you're sending not the same request or there is a difference in the tools configuration.
The most possible reason could be proxy, by default Loadrunner respects underlying operating system proxy settings and in JMeter you need to configure the upstream proxy connection manually, see Using JMeter behind a proxy article for more details
Another reason could be incorrect request configuration, i.e. protocol/host/port/path mismatch
And last but not the least, maybe your connect/response timeouts are too low, try ramping them up, the relevant setting lives under "Advanced" tab of the HTTP Request sampler (or even better go for HTTP Request Defaults)
Make sure that whatever the endpoint you try to access with this Jmeter script does not expect mutual SSL validation.
Then make sure that your token is generated from CA signed token generator before making the request.
Make sure that your connection timeout is not enough to respond after the request is made and make sure that the timeout is larger than the ramp-up time period.

Connection timeout expired while connecting to impala with impala JDBC Driver

I am using impala2.12.0-cdh5.16.1 and connecting to impala with impala_jdbc_2.6.4.1005. Normally it runs very well, but when I run distcp (which cost the Cluster Network IO and HDFS IO), the java program may throw errors.
2019/02/28 12:54:26 531873 ERROR run.QihooStatusTask(run:88) - [Cloudera][ImpalaJDBCDriver](700100) Connection timeout expired. Details: java.net.ConnectException: Connection timed out.
java.sql.SQLException: [Cloudera][ImpalaJDBCDriver](700100) Connection timeout expired. Details: java.net.ConnectException: Connection timed out.
at com.cloudera.impala.hivecommon.core.HiveJDBCCommonConnection.handleException(Unknown Source)
at com.cloudera.impala.jdbc.core.LoginTimeoutConnection.connect(Unknown Source)
at com.cloudera.impala.jdbc.common.BaseConnectionFactory.doConnect(Unknown Source)
at com.cloudera.impala.jdbc.common.AbstractDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:270)
The full error Message is in the picture:
I tried to add DriverManager.setLoginTimeout(120) to the program,but the error still exists.
I think it may be happen because the Cluster Network IO is very high and there may be a parameter which can add the value of timeout so the error will disappear.
So, any suggestion about this? Thx.

java runtime 6 with socks v5 proxy - Possible?

I have written an application that (amongst other things) runs a local service in windows that acts as a SOCKS v5 proxy for Firefox.
I'm in the debugging phase right now and have found certain websites that don't work correctly. For example the Java Applet for Picture Uploading on Facebook.com fails because is is unable to lookup domains.
My app overrides a hidden FF config setting network.proxy.socks__remote__dns setting it to true. The whole purpose of the app is to allow access to websites when behind a firewall (e.g. if the user is in China), so this setting is essential to ensure domains are resolved remotely also (and not just HTTP requests).
In the JRE6 settings (documented here) there isn't an equivalent setting, and since remote DNS resolution is a feature of SOCKS v5 and not v4 as the documentation seems to imply I'm worried that it's just not possible.
How can I programmatically make sure the JRE uses a SOCKS v5 proxy for all requests (including DNS)?
UPDATE:
Steps to reproduce this problem:
Make sure you are behind a firewall that blocks (or redirects) internet access including DNS
Install PuTTY and add a dynamic SSH tunnel on some port number of your choice (e.g. 9870). Then login to a remote server that has full access to the internet
Launch Firefox and you will not be able to browse the web
In FF network settings set the SOCKS v5 proxy to localhost:9870
In FF go to about:config, change network.proxy.socks__remote__dns to true
You will now be able to browse the web.
Go to facebook.com, login, go to your profile and attempt to use the picture uploader java applet to add some pictures
It will fail with a series of class not found errors looking similar to:
load: class com.facebook.facebookphotouploader5.FacebookPhotoUploader5.class not found.
I believe this is failing because the JRE is unable to resolve the domain that the class resides on. I'm basing this belief on the fact that the documentation (http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/properties.html) talks only about SOCKS v4 (which as far as I know does not support remote DNS). My deployment.properties file is located in %APPDATA%\Sun\Java\Deployment. I can confirm that modifications I make in the Java Control Panel get written into that file. If instead of "Use browser setting" the network settings for Java I override and attempt to use the SOCKS proxy settings manually, I still have the issue. There does not seem to be an easy way to force the JRE to do DNS remotely through the Proxy.
UPDATE 2:
Without the SOCKS proxy, from my local client
www.facebook.com resolves to 203.161.230.171
upload.facebook.com resolves to 64.33.88.161
Neither host is reachable (because of the firewall)
If I login to the remote server, I get:
www.facebook.com 69.63.187.17
upload.facebook.com 69.63.178.32
Both these IPs change after a few minutes, as it seems Facebook uses round-robin DNS and other load-balancing.
With the Proxy settings set in Firefox, I can navigate to www.facebook.com without any difficulty (since DNS is being resolved remotely on the Proxy). Whey I go to the page with the Java applet it fails with the stacktrace messages I've already reported.
However if I edit Windows\System32\drivers\etc\hosts, adding the correct IP for upload.facebook.com I can get the applet to load and work correctly (restart of FF is sometimes necessary).
This evidence seems to support my theory that the Java Runtime is not resolving DNS on the Proxy, but instead just routing traffic though it.
My application is for mass-deployment, and needs to work with java applets on other sites (not just facebook). I really need a work-around for this problem.
UPDATE 3
Stacktrace dump a requested by ZZ Coder:
load: class com.facebook.facebookphotouploader5.FacebookPhotoUploader5.class not found.
java.lang.ClassNotFoundException: com.facebook.facebookphotouploader5.FacebookPhotoUploader5.class
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 7 more
Exception: java.lang.ClassNotFoundException: com.facebook.facebookphotouploader5.FacebookPhotoUploader5.class
Dumping class loader cache...
Live entry: key=http://upload.facebook.com/controls/2008.10.10_v5.5.8/,FacebookPhotoUploader5.jar,FacebookPhotoUploader5.jar, refCount=1, threadGroup=sun.plugin2.applet.Applet2ThreadGroup[name=http://upload.facebook.com/controls/2008.10.10_v5.5.8/-threadGroup,maxpri=4]
Done.
new InetSocketAddress(hosta, port) which resolve IP by Default, and SocksSocketImpl use IP first if the target address is resolved.
If you want RemoteDNS, you can new Socket you An Proxy,then connnect to a InetSocketAddress which is constructed by InetSocketAddress.createUnresolved(host, port).
You Socks Server must be SOCKS5, java SocksSocketImpl auto detect is version.
Proxy p = new Proxy(Proxy.Type.SOCKS, paddr);
Socket s = new Socket(p);
InetSocketAddress addr = InetSocketAddress.createUnresolved("host.blocked.by.gfw", port);
s.connect(addr);
JRE certainly supports Socks V5. I have been using it since Java 1.4. JRE only uses V4 if your SOCKS server is V4. The first byte from your server response must be 5.
The V4 support was buggy. It only works with IP address, not domain name because it doesn't know how to resolve the domain name before hand. So you must be use V5 if Socks works at all.
I suspect that your proxy setting is incorrect so socks doesn't work at all. This should be easy to trace with Wireshark. Just check which port the applet is using.
Also the stacktrace will be very helpful. It will show you if Socks is used. For example,
load: class test.MyApplet.class not found.
java.lang.ClassNotFoundException: <name>.class
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: Malformed reply from SOCKS server
at java.net.SocksSocketImpl.readSocksReply(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
I pointed SOCKS proxy to my HTTP server so this error is expected.

Resources