I have a java program which calculates the distance and the journey time between two locations using the google matrix distance API. when I run my program everything goes fine but after a while I get this error:
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:606)
Any ideas?
Thank you.
The error message "java.net.SocketTimeoutException: connect timed out"
suggests that the root cause of the problem is due to network connectivity failure. This could have been caused due to these issues:
Google Distance API is a paid service, which requires billing account. Connectivity to API may fail when quota / billing had exhausted.
API requires a key for authorization. Connectivity can fail if the key had expired.
Network connectivity failed between the client computer and the API had failed, possibly due to a faulty internet connection.
Verifying the billing account, API key and network connectivity can help resolve the issue.
Related
I need to use Firebase Admin Java in my AWS Lambda project, but Firebase Auth Admin throws a SocketTimeoutException when it tries to fetch a Public Key within the Google's servers. I know Firebase Admin is configured correctly, because I can run it locally in a Tomcat instance with no worries.
I tried then to just make an HTTPS Request to a test API like https://postman-echo.com/get?foo1=bar1&foo2=bar2, and it has the same behavior, I get a timeout as well, which leads me to think that this is a problem with Lambda invoking an HTTPS Request.
Now what I know:
My lambda is integrated with API Gateway
My lambda is inside a subnet with internet access through an Internet Gateway
My lambda's Security Group is wide open
I know this problem happens on HTTPS Requests, I am not sure about pure HTTP. This is hard to test because I can't find an API out there that will not automatically redirect from HTTP to HTTPS, and I can't roll my own right now.
Just for the sake of completeness I will leave here the SocketTimeoutException I get from Firebase Admin Java, although I am not sure yet if this is a problem within the Firebase Admin library or with AWS Lambda + HTTPS or both together:
[main] ERROR com.example.project.filters.FirebaseAuthenticationFilter
- Error while parsing or validating the token com.google.firebase.auth.FirebaseAuthException: Error while verifying
signature. at
com.google.firebase.auth.FirebaseTokenVerifierImpl.checkSignature(FirebaseTokenVerifierImpl.java:160)
at
com.google.firebase.auth.FirebaseTokenVerifierImpl.verifyToken(FirebaseTokenVerifierImpl.java:92)
at
com.google.firebase.auth.FirebaseAuth$4.execute(FirebaseAuth.java:426)
at
com.google.firebase.auth.FirebaseAuth$4.execute(FirebaseAuth.java:423)
at
com.google.firebase.internal.CallableOperation.call(CallableOperation.java:36)
at
com.google.firebase.auth.FirebaseAuth.verifyIdToken(FirebaseAuth.java:388)
at
com.google.firebase.auth.FirebaseAuth.verifyIdToken(FirebaseAuth.java:362)
at
com.example.project.filters.FirebaseAuthenticationFilter.filter(FirebaseAuthenticationFilter.java:55)
at
org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:132)
at
org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:68)
at
org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
at
org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:269)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:272) at
org.glassfish.jersey.internal.Errors$1.call(Errors.java:268) at
org.glassfish.jersey.internal.Errors.process(Errors.java:316) at
org.glassfish.jersey.internal.Errors.process(Errors.java:298) at
org.glassfish.jersey.internal.Errors.process(Errors.java:268) at
org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:289)
at
org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:256)
at
org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:703)
at
com.amazonaws.serverless.proxy.jersey.JerseyHandlerFilter.doFilter(JerseyHandlerFilter.java:91)
at
com.amazonaws.serverless.proxy.internal.servlet.FilterChainHolder.doFilter(FilterChainHolder.java:84)
at
com.amazonaws.serverless.proxy.internal.servlet.AwsLambdaServletContainerHandler.doFilter(AwsLambdaServletContainerHandler.java:206)
at
com.amazonaws.serverless.proxy.jersey.JerseyLambdaContainerHandler.handleRequest(JerseyLambdaContainerHandler.java:184)
at
com.amazonaws.serverless.proxy.jersey.JerseyLambdaContainerHandler.handleRequest(JerseyLambdaContainerHandler.java:76)
at
com.amazonaws.serverless.proxy.internal.LambdaContainerHandler.proxy(LambdaContainerHandler.java:177)
at
com.amazonaws.serverless.proxy.internal.LambdaContainerHandler.proxyStream(LambdaContainerHandler.java:209)
at
com.example.project.StreamLambdaHandler.handleRequest(StreamLambdaHandler.java:39)
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:498) at
lambdainternal.EventHandlerLoader$StreamMethodRequestHandler.handleRequest(EventHandlerLoader.java:350)
at
lambdainternal.EventHandlerLoader$2.call(EventHandlerLoader.java:888)
at lambdainternal.AWSLambda.startRuntime(AWSLambda.java:293) at
lambdainternal.AWSLambda.(AWSLambda.java:64) at
java.lang.Class.forName0(Native Method) at
java.lang.Class.forName(Class.java:348) at
lambdainternal.LambdaRTEntry.main(LambdaRTEntry.java:114) Caused by:
java.net.SocketTimeoutException: connect timed out 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:666) at
sun.net.NetworkClient.doConnect(NetworkClient.java:175) at
sun.net.www.http.HttpClient.openServer(HttpClient.java:463) at
sun.net.www.http.HttpClient.openServer(HttpClient.java:558) at
sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:264) at
sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:367) at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1156)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1050)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:162)
at
com.google.api.client.http.javanet.NetHttpRequest.execute(NetHttpRequest.java:104)
at
com.google.api.client.http.HttpRequest.execute(HttpRequest.java:981)
at
com.google.api.client.googleapis.auth.oauth2.GooglePublicKeysManager.refresh(GooglePublicKeysManager.java:172)
at
com.google.api.client.googleapis.auth.oauth2.GooglePublicKeysManager.getPublicKeys(GooglePublicKeysManager.java:140)
at
com.google.firebase.auth.FirebaseTokenVerifierImpl.isSignatureValid(FirebaseTokenVerifierImpl.java:226)
at
com.google.firebase.auth.FirebaseTokenVerifierImpl.checkSignature(FirebaseTokenVerifierImpl.java:152)
... 38 more
My lambda is inside a subnet with internet access through an Internet Gateway
An Internet Gateway alone will not provide a Lambda function residing in a VPC access to the Internet. This is because Lambda functions inside a VPC do not receive public IP addresses. You have to use a NAT Gateway to provide Internet Access to a Lambda function inside a VPC.
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.
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.
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