I need to write an unit test to check the behavior of http connections in case the remote service is being restarted. Is it possible to simulate such a situation with wiremock ?
Related
I'm trying to think through the advantages and disadvantages of haproxy health checks happening on a different port from regular traffic.
If a server becomes overloaded having health checks on a different port may mark the server as being up even when overloaded. I think this is a good thing because taking servers offline may make an overloading problem worse, but want to confirm that that makes sense. I can't seem to find any good docs on the tradeoffs though and was wondering if someone has a good analysis on the tradeoffs.
The port keyword is often used with address to send health checks somewhere else than directly to the service you are checking. One example might be enabling option httpchk to monitor a non-HTTP service. What you then do is have a HTTP-compatible service that when queried can execute complex health checks against the service you are actually testing.
The above is often done with agent-check nowdays, but some people prefer to use an HTTP interface.
This also has nothing to do with server load, the only idea is to send health checks to some other service, not the one directly monitored, which is more capable of testing the actual service (possibly by using a more-complex logic) and returning a result. As an example, one could have a MySQL backend which instead of being tested just for authentication by option mysql-check, could be tested by a PHP script that, for example, checks if backup is running and if it is returns a 5xx HTTP error. The configuration could be something like:
backend mysql
mode tcp
option httpchk GET /mysql-status.php
server mysqlserver 10.0.0.1:3306 check port 80
I set variables host and port instead of setting the 'address' variable tuple in socket.py. I was unable to get 'address' as a tuple to work. I do not believe this is the issue, but I thought I should state this up front.
FYI, my goal is an integrations project, and I believe I isolated socket.py as the problematic code. socket.py is not creating a listener on the remote server. I run the python script on my client, and my server address is 192.168.1.130 port 7879.
I think socket.py is the problem, because I do not receive the expected print statements back through the console that socket.py is attempting to create a socket. In addition, I can RDC to the server, disable ufw (yes I know this is a bad idea), create a tcp listener, push data through the client socket to the server socket, and verify this with netcat.
Am I mistaken that I should be able to parameterize socket.py with nothing more than a host and port and be able to create a socket connection? I am happy to provide more detail from logs, but I thought I should start with a very high level overview.
Answer: More investigation needed. I think socket.py does not create the remote connection with socket(),bind(),listen() statements; instead simply looks for a listener on the remote server with a connect() statement. This is entirely my misunderstanding given I did not dive into the details of the socket.py code. I figured this out because the service running on the remote server creates the listener, but the service itself on the remote server is what is not properly starting.
I have one Batch job on one server which is intern calling the service on the other server.
The issue is-(we suspect)the batch job is unable to call the service,but we are not very sure.
How to ensure that service is not getting called from the network point of view.
we checked telnet between the two servers which is fine.
Is this the only way to troubleshoot?
note: we can not do the code level changes now.
You could make use of tools like wireshark or
tcpdump to capture the network traffic and see that your script is indeed sending o/g requests.
As far as I can see there is no way to run Akka remote tcp client placed behind a firewall, because every Akka peer has to have a tcp server socket to be able to receive messages. Am I right?
I need to create a pure tcp client with Akka that would be able to connect to a remote server and receive responses from it but unable to receive incoming connections.
Yes you are. All akka nodes should be able to receive incoming requests.
Typically response is posted into a akka queue.
I doubt if it can happen without an incoming connection.
I guess you need to go through a proxy server.
In order to do that you need to pass the httpProxy and httpPort flag to the JVM.
You can do that with "-J" switch or passing in the JAVA_OPTS environment variable
When deploying a web application running on a traditional web server, you usually restart the web server after the code updates. Due to the nature of HTTP, this is not a problem for the users. On the next request they will get the latest updates.
But what about a WebSocket server? If I restart or kill the old process all connected users will get disconnected. So my question is, what kind of strategy have you used to deploy a WebSocket server smoothly?
You're right, every connected user will be disconnected if the server restarts.
I think the less bad solution is to tell to the client to reconnect in the onClose method of the client.
WebSockets is just a transport mechanism. Libraries like socket.io exist to build on that transport -- and provide heartbeats, browser fallbacks, graceful reconnects and handle other edge-cases found in real-time applications.
In our WebSocket-enabled application, socket.io is central to ensuring our continuous deployment setup doesn't break users' active socket connections.
If clients are connected directly to sever that does all sockets networking and application logic, then yes - they will be disconnected, due to TCP layer that holds connection.
If you have gateway that clients will be connecting to, and that gateway application is running on another server, but will communicate and forward messages to logical server, then logical server will send them back and gateway will send back to client responses. With such infrastructure, you have to implement stacking of packets on gateway until it will re-establish connection with logical server. Logical server might notify gateway server before restart. That way client will have connection, it will just wont receive any responses.
Or you can implement on client side reconnection.
With HTTP, every time you navigate away, browser actually is creating socket connection to server, transmits all data and closes it (in most cases). And then all website data is local, until you navigate away.
With WebSockets it is continuous connection, and there is no reconnection on requests. Thats why you have to implement simple mechanics when WebSockets getting closing event, you will try to reconnect periodically on client side.
It is more based on your specific needs.