I have a http client that connects to the same api endpoint on different servers. Which server it connects to, depends on business logic.
Let's say the http client method is connect(url). How can I make sure that the circuit breaker takes the url into account? If my http client sends requests to both url_A and url_B , and server A goes down, then I want that my http client can still send requests to server B.
Does Failsafe or Resilience4J support this out-of-the-box?
Related
I have a REST API written in java and spring which makes a backend call to a SOAP service. The SOAP web service code are packaged in a 3rd party jar. So don't have access to change the code. But I can change the SOAP service endpoint by setting a env variable.
How can I capture the raw SOAP request sent by the REST API?
You can intercept the SOAP Request by using number of tools.
I would suggest either use TCPMonitor (https://ws.apache.org/tcpmon/tcpmontutorial.html) or wiresharks (https://www.wireshark.org/).
TCPMonitor acts like a proxy (So your endpoint should point to TCPMonitor), and it will relay the message back to your service.
Wireshark is a network protocol analyser. It captures all the TCP/UDP packets (which includes the HTTP as well). You just have to capture the packets. No modifications from server and client ends required. You can then filter the HTTP/HTTPS packets to look for your requests.
You can always use a network packet Analyser such as tcpdump or wireshark to capture packets sent specifically to your 'endpoint'.
ALTERNATIVELY
You can write a tiny proxy to capture requests on a local port and forward them to the actual endpoint and route response after printing it to sys-out. You, in that case, will specify the proxy as the endpoint to your program.
I am not sure of any existing proxy which does that, but I think haproxy will not.
If you're on Windows, you can use ProxyTrace, PocketSoap, and other PocketSoap.com tools.
I'm developing a Java API for an Adndroid app in Spring. Right now my API is 100% REST and stateless. For the client to receive data, it must send a request first.
However, what I need is the server to send data to the to the client /not the client to the server fisrt/ whenever it is ready with it's task.
I think that some kind of session must be created between the two parties.
My question is: How can I achieve this functionality of the SERVER sending data to the CLIENT when it's ready with it's task? /It is unknown how long the task will take./
What kind of API should I develop for this purpose?
One idiotic workaround is sending a request to the server every n seconds but I'm seeking for a more intelligent approach.
There are multiple options available. You can choose what suits best for you.
Http Long Polling - In this, server holds the request until it's ready with its task (in your case). Here, you don't have to make multiple requests every few seconds (Which is Http Polling).
Server Sent Events - In this, server sends update to the client without long-polling. It is a standardized part of HTML 5 - https://www.w3.org/TR/eventsource/
Websockets - Well, websockets work in duplex mode and in this a persistent TCP connection is established. Once TCP connection is established, both server and client sends data to and fro. Supported by most modern browsers. You can check for Android Websocket Library like autobahn and Java websocket.
SockJs - I would recommend to go with this option instead of plain WebSocket. http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#websocket-fallback-sockjs-enable
We have a Java web service with document style and http protocol. Local this service works smoothly and fast (~ 6ms). But calling the service-methods from remote takes over 200ms.
One main reason for this delay is that the
server sends first the response http header,
the client sends in return a ACK and
then again the server sends the response http body.
This second step where the client sends the ACK costs the most time, almost the whole 200ms. I would like to avoid this step and save the time.
So that's why my question: Is it possible to send the whole response in one package? And how and where do I configure that?
Thanks for any advice.
I'm not fully understanding the question.
Why is the server sending the first message? Shouldn't the client be requesting for a web service via HTTP initially?
From what I understand, SOAP requests are wrapped within an http message. HTTP messages assumes a TCP connection and requires a response. This suggests that a client must respond when the server sends an http header.
Basically whatever one end sends to another, the other end must reply. The ACK return from you step 2 will always be present.
EDIT:
I think the reason for the difference in time when requesting via local and remote is simply the routing that happens in the real network versus on your local machine. It's not the number of steps taken in your SOAP request and response.
I have a complete implementation of a protocol where four messages are exchanged between the client (a native Android application) and the server (a standalone Java server) in the following way using a persistent connection through Java sockets:
(client->server): message1
(server->client); message2
(client->server): message3
(server->client): message4
Between sending each message, both client and server have to do heavy mathematical (cryptographic) operations (pairing-based computations over elliptic curves).
This project works properly in my local development machine using sockets and mantaining opened this socket from message1 to the message4 between the Android app and the Java server. Now, I need to do the same with Google AppEngine, but since it does not allow opening sockets, I do not know how can I do it. I already checked the Channel and XMPP APIs, but I do not know whether my use-case applies to that APIs. Is it the right method using Channel and XMPP APIs from AppEngine? Is it possible to emulate the functionality implemented in my local machine through sockets on AppEngine?
Thank you for your response.
Google App Engine doesn't support persistent connections.
You will need to significantly re-design your protocol to run over HTTP.
As an example, message1 can be sent over an HTTP request, message2 can be returned with the matching HTTP response. At that point, your socket connection ends.
You'll have to issue a second HTTP request to open a new socket with message3, and you can return message4 with the second HTTP response.
You can "connect" the first and second HTTP request by using an HTTP session. A session is basically an id with extra data stored on the server side. You'd create the session in the first HTTP request, and pass it as a parameter to the second HTTP request. The server can look up the session id and the associated data when processing the second request.
You can find more info about sessions on SO: How to use session on Google app engine
The XMPP API will not help you, it's for communicating between the GAE server-side code and other XMPP clients that use HTTP as a communcation protocol.
The Channel API can be used to send data from the server->client, but it's actually implemented as an HTTP long poll. Multiple long HTTP requests are used, and you are not guaranteed to have a single socket that stays open; multiple sockets are opened and closed in the process. It will be more complicated that what I described above, and more expensive.
I am going to write a smart client application. This application will be swing based desktop client that will communicate with web service. I want to be a message has been sent to client from web service when any change occurs at server side file system. I wanted to use web services but I am not sure how I would implement a two-way communication between the server and client. Is it possible? If so how? If not what are the alternatives?
You have to program your client to be able to ping a request after a predefined frequency to check if there is a changes occurred on the server side. The client expect the changes occurred on the server or null if no change.