I am trying to run my load test on jmeter for REST api which is returning JSON.
I am passing the following header information in Header manager
Authorization: Bearer VHFAJ0dxNQfJlzPmr7miaH4QOFeNVmez6RXVHX59uovrFAL6z5zMv9krpBAvOcNTwqHRFa8REaidlpuJSUMF8Ol38t7n-sHP2WQn0KmrEnFrtdo6XDRdhspVP1D72oIlu9sP_-rdv1MdsnakVewqrzZ9PeDiWhVKqRBTjWVlnZFpLS-CZ86DFanQ9cw7VZ67a1yOWC7_os7vZYeIhaQ8dM_8n_ocYzFDcCHELSGqnz3NHc9DRrQQfjM6xB17aRjUKQ4ZNV52Ss_1BKG8-5H7bMpi1QiAdDS17K55WrNAZMzgHeaP6UwtQwJyo_gxiaW5PlNJZNQQn4rZvNkIRd_V9Q
Content-Type: application/x-www-form-urlencoded
Accept: application/json
Few days ego I tried the same test on local internal server and it was working fine. Now I am running this on UAT env which is setup on AWS.
This is working fine with chrome Postman extension.
Also I have followed the below link but no success and getting the socket closed exception
Non HTTP response message: The target server failed to respond: Is my server failing to handle load
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:127)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.open(MeasuringConnectionManager.java:107)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:517)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:331)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1146)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1135)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:434)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:261)
at java.lang.Thread.run(Thread.java:745)
Please let me know if more information is required
If your UAT deployment is behind Elastic Load Balancer or Elastic IP it may be the situation when JMeter resolves IP address of only one server and it becomes overloaded while others are idle.
Try adding DNS Cache Manager to your Test Plan to see if it helps. Check out The DNS Cache Manager: The Right Way To Test Load Balanced Apps guide for more information on the domain.
You should read this:
https://wiki.apache.org/jmeter/JMeterSocketClosed
Note Socket closed can be an issue with your server.
Related
I'm setting up google recaptcha on my java application and I'm getting connect timeout:
Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to www.google.com:443 [www.google.com/172.217.168.164] failed: connect timed out
at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:134)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:138)
HttpClientHelper.java:138
... 2 more
Caused by: java.net.SocketTimeoutException: connect timed out
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:244)
at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:1
To test if there was any problem with the network, I made the same request using Postman and cURL, both returned the expected response. Then I used postman to generate java code, ran it and got the same error.
Notice that in order for the request to work with Postman I had to turn off "Use System Proxy". This lead me to think that maybe java was using system proxy by default and tried to disable it with System.setProperty("java.net.useSystemProxies", "false"); (also tried with true). Still got same error.
Here is a example of the code used:
HttpResponse<String> response = Unirest.post("https://www.google.com/recaptcha/api/siteverify")
.header("response", "abc")
.header("secret", "abc")
.asString();
Thanks in advance.
Like so often, the reason was dead simple:
The target server only has an IPv4 address. Java for some reason tries to access the target using IPv6 and fails to do so. I assume that this kind of "halts" the ongoing process and this can only be remedied by aborting the hanging thread (what the timeout effectively does)
As soon as I addded -Djava.net.preferIPv4Stack=true to the call of my program, I was able to run it successfully.
source: HttpClient hits timeout but server is available and working flawlessly
maybe?
I wrote a multi-server chat system based on Java under Windows. At the security part, I created one keystore to create the SSLSocket. When I launch 3 servers, it works on Windows(Win10 14393.321) but fails on OS X(Version 10.12 (16A323)) and Linux(Ubuntu 14.04.4 LTS). It really confused me. Here is the keystore part:
System.setProperty("javax.net.ssl.keyStore",keyFilepath);
System.setProperty("javax.net.ssl.trustStore",keyFilepath);
System.setProperty("javax.net.ssl.keyStorePassword","password");
System.setProperty("javax.net.ssl.trustStorePassword", "password");
And when I run the third server on OS X or Linux, it shows:
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method) at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at
java.net.Socket.connect(Socket.java:589) at
sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) at
sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:427) at
sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88)
at server.AuthorizeServer.MessageReceive(AuthorizeServer.java:99) at
server.AuthorizeServer.main(AuthorizeServer.java:64) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497) at
org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
This is my first time asking on StackOverflow and I really looking forward to your kind help.
Thanks!
java.net.ConnectException: Connection refused
Connection refused is an error message from the TCP stack and means that it could not connect with TCP to the other side. Since SSL/TLS is a layer on top of TCP and is only started once the TCP connect succeeded it means that the problem is not caused by different behavior at the SSL/TLS layer.
That this is not cause by the SSL layer but the TCP layer can also be seen by the stacktrace: Connection refused at java.net.PlainSocketImpl.socketConnect
More likely is that there is something blocking the TCP connection (firewall) or that you've tried to listen/connect to the wrong IP address (e.g. trying to reach a server listening on 127.0.0.1 on Windows from the Linux system). But is impossible to say from the currently provided information what exactly is the case.
My Windows 7 is providing FTP service using FileZilla Server. On the other hand, a Debian client would like to access the FTP server via Apache FTPsClient. The way I construct the client is shown below:
FTPSClient client = new FTPSClient("TLS", true);
client.setAuthValue(authValue);
client.configure(new FTPClientConfig(FTPClientConfig.SYST_UNIX));
client.connect("127.0.0.1", 990);
client.login("username", "password");
client.execPBSZ(0);
client.execPROT("P");
client.enterLocalPassiveMode();
With the above client on Windows, I can successfully retrieve a list of directory in my FTP server. The same client on Debian is however failed to connect to my Windows server. May anyone give me a hand? Many Thanks^^
The Debian client throws the following exception:
java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:188)
at org.apache.commons.net.SocketClient.connect(SocketClient.java:209)
while there is no log for the above connect event.
First of all, many thanks to Martin Prikryl.
Following setup guide, I've created a rule on Firewall allowing access on a port for normal FTP file transfer, but haven't for port 990. After creating new rule for port 990, everything works.
The setup guide for reference
http://www.howtogeek.com/140352/how-to-host-an-ftp-server-on-windows-with-filezilla/
I tried to start application on remote host and received the below exception
message java.net.ConnectException: Connection refused: connect
description The server encountered an internal error that prevented it from fulfilling this request.
exception
javax.servlet.ServletException: java.net.ConnectException: Connection refused: connect
com.vaadin.terminal.gwt.server.AbstractApplicationServlet.handleServiceException(AbstractApplicationServlet.java:1010)
com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:548)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
root cause
java.net.ConnectException: Connection refused: connect
java.net.DualStackPlainSocketImpl.connect0(Native Method)
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
java.net.Socket.connect(Socket.java:579)
java.net.Socket.connect(Socket.java:528)
sun.net.NetworkClient.doConnect(NetworkClient.java:180)
sun.net.www.http.HttpClient.openServer(HttpClient.java:378)
sun.net.www.http.HttpClient.openServer(HttpClient.java:473)
sun.net.www.http.HttpClient.<init>(HttpClient.java:203)
sun.net.www.http.HttpClient.New(HttpClient.java:290)
sun.net.www.http.HttpClient.New(HttpClient.java:306)
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:995)
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:931)
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:849)
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1299)
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:633)
com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:189)
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:799)
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210)
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:568)
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:302)
scala.xml.factory.XMLLoader$class.loadXML(XMLLoader.scala:40)
scala.xml.XML$.loadXML(XML.scala:40)
scala.xml.factory.XMLLoader$class.load(XMLLoader.scala:54)
scala.xml.XML$.load(XML.scala:40)
com.exo.AppUser.<init>(AppUser.scala:17)
com.exo.OdaWebApplication.<init>(OdaWebApplication.scala:24)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
java.lang.reflect.Constructor.newInstance(Constructor.java:526)
java.lang.Class.newInstance(Class.java:374)
com.vaadin.terminal.gwt.server.ApplicationServlet.getNewApplication(ApplicationServlet.java:82)
com.vaadin.terminal.gwt.server.AbstractApplicationServlet.createApplication(AbstractApplicationServlet.java:984)
com.vaadin.terminal.gwt.server.AbstractApplicationServlet.findApplicationInstance(AbstractApplicationServlet.java:807)
com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:456)
javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
i tried figuring out the reason and checked some issues but it's still not working
i found some information about it, but it was helpless
i checked some issues like:
service not listening - catalina logged about listening
firewall bocked request - no firewall, no antivirus
user can't connect to server - it's running only in localhost
application don't work - correctly work from IDE
Application run correctly from IDE, and also before host restart.
I can't understand why this is happening.
You've missed the point. You have connected to your Servlet. That's how you got the 500 status back from it. Something in the servlet has failed to connect to something else, while it was doing some XML process.
To diagnose the problem follow the list:
telnet the hostname and port from command line telnet {hostname} {port}
If the connection is established it is not an application error, but network problem
look you are not using proxy - if so you need to setup proxy for your application
If connection refused either there is something wrong with your application and possibly with network either.
Its definitely one of the 4 points you listed
OR
you are hitting the wrong port number?
if that is not in those 4 points then Can You check whether the server is started successfully. may be there is a chance of Java Core(.txt file) generation(tomcat/bin folder). so server will not be started perfectly and also there might be chance of corruption in deployment directory. you can redeploy and check.
I'm running a loadtest on a brand new Windows 2008 64 bit machine.
The loader is a Java Applet which uses an HttpURLConnection to post requests to the server which is listening on a ServerSocket.accept(), both loader and server are running on the same machine.
On my old Windows 2003 server I was able to load over a 1000 users using this configuration.
However, with the new server, when loading around 400 sessions the loader starts throwing the following exception:
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:69)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:337)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:198)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:157)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:388)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:483)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:213)
at sun.net.www.http.HttpClient.New(HttpClient.java:300)
at sun.net.www.http.HttpClient.New(HttpClient.java:316)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:992)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:928)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:846)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1087)
...
It looks as if the server or the machine is running out of some resource.
The ServerSocket backlog is set to 256 and it looks like it is not being exhausted.
The machine cpu utilization is less than 10% and the server has plenty of available memory.
Observing the client and server using Visual VM it looks like both are functioning properly at the time of the problem.
Any ideas ?
Maybe server is rejecting connections due to lack of some other resources? Each HTTP requests will require opening TCP connection, which under Linux uses 'file' (I'm not Linux expert, so please correct me if I'm wrong). So sometimes CPU and memory are low, but HTTP server opens hundreds of files which in the end causes failure and any further request will be rejected.
I'm not sure if this applies to Windows as well, but give it a shot.
There are some additional limitations imposed in 2008 that were not part of previous versions. I would start here... http://technet.microsoft.com/en-us/magazine/2007.12.network.aspx