I looked for solutions on SO for this but none of them seem to apply to my case. So here goes:
I have an application that needs to make a service call to a third party domain. I am using jersey client to make this service call. The code for making this call is
ClientResponse resp = resourceWithParams.
header("Authorization", getAccessKeyId() + ":" +
hmacSha1.toUpperCase()).
post(ClientResponse.class,"");
where resourceWithParams is the jersey web resource. Note that even though its is a POST, the web service is expecting a query string and empty body. It might be questionable design but that is what we have to work with.
This setup is working just fine on my local machine as well as on our preprod server. However on our production servers it gives an exception:
com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused
There are a couple of points below that might be helpful in pointing me in the right direction:
1) We get a valid response when we use curl on the prod server command line to send a request to the web service so seems like there are no firewall issues. This is happening only when we try it through the web application, i.e. through the java code using jersey client.
2) There are no proxies set up on the prod servers
3) Works fine from localhost.
4) The Rest webservice uses https and the correct certificates are installed on our server which is proved by the fact that curling the webservice on prod works fine.
Any ideas on what the issue might be and where we should start looking?
EDIT:
As mentioned we were using https to connect to the webservice. If we use http instead, it does seem to be working.
I suggest you set up a tcpdump session to see where the connection refused is coming from. In particular, see what the source IP and destination IP addresses are, for both the successful connections and the unsuccessful ones.
There are two possibilities the above is designed to test for:
You say you're not using proxy servers, but Java actually has a separate proxy configuration from the rest of the system, so it may be that your Java is configured to use a non-functional proxy server.
Your Java system could be sending requests using a different source IP address to the one that your curl is using.
Related
I'm trying to configure the WSO2 API Manager. (version - v4.0.0)
When I try to create REST API and point to the endpoints I"m getting a Connection error message for the given endpoints. I have hosted the API Manager and the back end services on the same server(backend services are running on the tomcat application on the same server in port 8080)
API Manager Log produces the following message :
ERROR {org.wso2.carbon.apimgt.rest.api.publisher.v1.impl.ApisApiServiceImpl} - Error occurred while sending the HEAD request to the given endpoint url: org.apache.commons.httpclient.ConnectTimeoutException: The host did not accept the connection within timeout of 4000 ms
would really like to what has caused the issue.
P.S: I can access the backend services directly without any connection issues using a REST client.
It's difficult to answer the question without knowing the exact details of your deployment and the backend. But let me try. Here is what I think is happening. As you can clearly see, the error is a connection timeout The host did not accept the connection within timeout of 4000 ms.
Let me explain what happens when you click on the Check Endpoint Status button. When you click on the Check Endpoint Status button, the Browser is not directly sending a request to the Backend to validate it. The Backend URL will be passed to the APIM Server, and the Server will perform the validation by sending an HTTP HEAD request to the BE service.
So there can be two causes. First may be your backend doesn't know how to handle a HEAD request which is preventing it from accepting the request. But given the error indicated it's a network issue, I doubt it even reached the BE.
The second one is, that your Backend is not accessible from the place API Manager is running. If you are running API Manager on Server A and trying to access API Manager via browser from Server B(Local Machine). Although you can access the BE from Server B may be from Server A it's not accessible. When I say BE is not accessible from API Manager server, it means it's not accessible with the same URL that was used in API Manager. It doesn't really matter if it runs in the same Server if you are using a different DNS other than localhost to access it. So go to the server API Manager is running and send a request using the same URL that was used in API Manager and see whether it's accessible from there.
First try doing a curl request by login into the server where APIM is running (not from your local machine). Maybe due to some firewall rules within the server, the hostname given in the URL may not be accessible. Also, try sending a HEAD request as well. You might be able to get some idea why this is happening
I was working on a ktor project and everything was working fine. I started the server and it was working fine on port 8080 but now for some reason suddenly it stopped working. I killed the task and tried everything, I'm not sure what's wrong. I tried to reinstall IntelliJ Idea and I'm still facing the same issue. I tried using 127.0.0.1
, 0.0.0.0
, localhost but none of them work idk what to do. I've wasted like 2 hours on this thing. I've tried changing port, blocking firewall and antivirus.
change 127.0.0.1(localhost) to your private ip like 172.30.1.59 if you use wifi. if you use fixed ip then use it. i have same problem, but solve it with this. Nice!
cmd -> ipconfig -> use ip address
I usually had the same issue using Ktor and it is frustrating. Then I am gonna post the following possible fixes that you should try in order and reading the steps. I am going to consider that you are running a WebSocket server and a WebSocket client for your Android app in a unique computer.
You are running the server side and the client using the same ip and
it should not work, because the client can not connect to the
server. When I am testing a project that requires server-side and
client-side I use my computer to run the Android app and the laptop
to run the server side. If this is not your case, then, do
not pay attention.
In the client-side, when you create the instance of the HttpClient,
do you pass any value to the client as engine or you simply go
directly with lambda? From my experience, when I create the
HttpClient instance, only works these two following first ones:
val client = HttpClient {
install(WebSockets)
}
or
val client = HttpClient(CIO){
install(WebSockets)
}
The engine that doesn't work for me is:
val client = HttpClient(OkHttp) {
install(WebSockets)
}
Finally, when you create the WebSocket using the past client
instance, you should use
client.ws(
HttpMethod.Get,
"localhost",
8080,
"/"
)
{
//Client code
}
and not client.wss. That is because in local connection, your client
do not connect using TLS security and it will throw an exception. If
you're deploying your server-side in a hosting that has TLS security
as Heroku, then you can use the wss one, because the client-side
will connect using TLS certificate.
Hope that my response can help. Good luck!
I had the same problem and it turned out that it was because I had the HttpsRedirect and HSTS plugins installed. Due to this it refused to handle the http request and since I don't have any certificate for localhost or my local IP it didn't work.
Disabling these two plugins when running locally makes things work for me.
Follwing the steps as outlined here: Standalone web service
I created a test web service that works great on my local machine. Since this is 'stand alone' I copied the same root folder on to a 'server' that I use and published the service on the server (as if it is my local machine). When I access the wsdl using localhost as the domain name, it works fine on the server. However, when I try the url from a different macihne on the network giving the server's domain name instead of localhost, I get a 'can not be displayed' error in IE.
My question is, should this even be possible? Or is there anything specific that needs to be done. Since this is a 'stand alone' solution, we should not require 'another' container like tomcat correct?
To be honest, until your post, I had no idea there was a builtin, lightweight, HTTP Server in the JDK. I've always used glassfish for my web service needs.
I can't say for sure, but if you look closely at the example code you'll see:
Endpoint endpoint = Endpoint.publish("http://localhost:8080/calculator", calculator);
I suspect that this limits you to "localhost" as opposed to the host machine. Try changing it so that it represents the name of the server and try again from another machine (naturally making sure it can get through the firewall as well). Something like:
Endpoint endpoint = Endpoint.publish("http://myserver:8080/calculator", calculator);
Rebuild it and try again. Other than that, you'd need to create a proper war file and deploy to glassfish, tomcat, etc.
We have a number of Jetty http(s) servers, all behind different firewalls. The http servers are at customer sites (not under our control). Opening ports in the firewalls at these sites is not an option. Right now, these servers only serve JSON documents in response to REST requests.
We have web clients that need to interact with a given http server based on URL parameter or header value.
This seems like a straightforward proxy server situation - except for the firewall.
The approach that I'm currently trying is this:
Have a centralized proxy server (also Jetty based) that listens for inbound registration requests from the remote http servers. The registration request will take the form of a Websocket connection, which will be kept alive as long at the remote HTTP server is available. On registration, the Proxy Server will capture the websocket connection and map it to a resource identifier.
The web client will connect the proxy server, and include the resource identifier in the URL or header.
The proxy server will determine the appropriate Websocket to use, then pass the request on to the HTTP server. So the request and response will travel over the Websocket. Once the response is received, it will be returned to the web client.
So this is all well and good in theory - what I'm trying to figure out is:
a) is there a better way to achieve this?
b) What's the best way to set up Jetty to do the proxying on the HTTP Server end of the pipe?
I suppose that I could use Jetty's HttpClient, but what I really want to do is just pull the HTTP bytes from the websocket and pipe them directly into the Jetty connector. It doesn't seem to make sense to parse everything out. I suppose that I could open a regular socket connection on localhost, grab the bytes from the websocket, and do it that way - but it seems silly to route through the OS like that (I'm already operating inside the HTTP Server's Jetty environment).
It sure seems like this is the sort of problem that may have already been solved... Maybe by using a custom jetty Connection that works on WebSockets instead of TCP/IP sockets?
Update: as I've been playing with this, it seems like another tricky problem is how to handle request/response behavior (and ideally support muxing over the websocket channel). One potential resource that I've found is the WAMP sub-protocol for websockets: http://wamp.ws/
In case anyone else is looking for an answer to this one - RESTEasy has a mocking framework that can be used to invoke the REST functionality without running through a full servlet container: http://docs.jboss.org/resteasy/docs/2.0.0.GA/userguide/html_single/index.html#RESTEasy_Server-side_Mock_Framework
This, combined with WAMP, appears to do what I'm looking for.
I am working on a project
1.which requires several processes to be listening for requests on unique ports(possibly on multiple hosts)
2.Every process is meant to serve a unique client
3.The clients should connect to there respective server process using client_id.domainname.com as the identifier / end point.
Ex:
requests coming to
client_id_1.domainname.com:FIXED_PORT should go to host_1:port_1
client_id_2.domainname.com:FIXED_PORT should go to host_2:port_2
etc..
[Edited for clarification : the port number with which client will access should be fixed.Only the client_id would change with change in client]
4.[Edited(had missed this point)]. The mapping needs to be dynamic/modifiable .Example if one the processes die ,another has to be brought up which might not be on the same port
I have tried the following approaches(using java)
1.implemented tcp server,and tried using tcp portforwarding using http://code.google.com/p/portforward/ and other similar stuff that i found by searching.The problem is this uses InetAddress which does not have the request uri(to get the client id using subdomain from uri)
2.implemented server processes as Servlets in embedded jetty.This is fine only for GET requests. GET requests can be redirected to specific server using
httpServletResonse.sendRedirect("http://host_1:port_1")
for POST we have RequestDispatcher which ultimately resuls in a GET.It seems that the HTTP specification doesnt allow a redirect with POST.
I also found this Calling the doPost in another Webapp with a Req Dispatcher forward which suggests to to fire a POST request yourself programmatically.(I havent still worked on this approach yet)
I hope there is a solution for this.
I might be highly oversimplifying, but I think this is similar to what HEROKU does.They also have backend processes(dynos) which run on different ports(i am not sure about this).They are matched with incoming requests based on the app-name.The following discusses
http://www.quora.com/Scalability/How-does-Heroku-work but this question is not answered.
I have been stuck for quite sometime on this.I would be realy thankful for your help.
This is not possible on the Heroku stack as it only supports the standard HTTP and HTTPS ports (80 & 443). When you spin up your process the port that the service is connected on is dictated by the Heroku infrastructure (See $PORT and Procfiles).
Trying to do anything that doesn't fit this model is not really going to work until they support more ports.