Is there a health endpoint for the Rocketchat server, we would like to use this to monitor availability of the server.
https://forums.rocket.chat/t/rocket-chat-on-docker-no-health-check/9106 says there isn't an endpoint available
There is not.
But you could build yourself a channel, which can have similar/same purpose. Upon receiving a Ping, to reply with OK or Pong or Success or anything that you expect, and if the channel does not reply in a given predefined timeout, that would trigger an alert that the service is down/slow..
My RocketChat container (image: docker.io/rocketchat/rocket.chat) has a health endpoint.
I'm not an expert in RocketChat but I think this PR introduced it: https://github.com/RocketChat/Rocket.Chat/pull/27026 (Not sure what is meant by data stream and if it is an overall health check.)
It is also indicated in RocketChat's Helm-Charts: https://github.com/RocketChat/helm-charts/blob/master/rocketchat/templates/chat-deployment.yaml
Related
I have an application in which clients use websockets to connect to a server which is running Spring Boot Tomcat.
My question is if there is a way for the server to detect a client disconnect due to a network loss.
Thanks.
if you are using stomp , check SessionDisconnectEvent.
For raw Websocket connections, you can use :
WebSocketHandler-->afterConnectionClosed
I have searched before for this and the solution I was able to find was to implement a ping-pong mechanism between the server and the clients.
For example, each few seconds send a dummy message to the client on a specific topic and receive back another dummy reply, if you didn't get a reply for a configured period you can consider the client disconnected.
As mentioned here,
STOMP and Spring also allow us to set up topics, where every
subscriber will receive the same message. This is going to be very
useful for tracking active users. In the UI, each user subscribes to a
topic that reports back which users are active, and in our example
that topic will produce a message every 2 seconds. The client will
reply to every message containing a list of users with its own
heartbeat, which then updates the message being sent to other clients.
If a client hasn't checked in for more than 5 seconds (i.e. missed two
heartbeats), we consider them offline. This gives us near real time
resolution of users being available to chat. Users will appear in a
box on the left hand side of the screen, clicking on a name will pull
up a chat window for them, and names with an envelope next to them
have new messages.
is it possible to create server based unsolicited "events", "messages"
(e.g. message that is NOT a reply to a client's request, but generated
on behalf of the server) in gRPC?
[Tried googling for it, but couldn't find any relevant answer, mind me]
Thanks,
If you want the server to initiate the connection from the server and send a message with no prior interaction from the client, then no, you can't do that with gRPC.
However, this fits perfectly into the "subscriber" pattern that gRPC is intended to support: the client opens a server-streaming request (possibly indicating which messages or events they would like to receive), then the server responds with each message or event as it appears.
I used client and the client will create a connection to server via HornetQ and Netty
Each of 1 minute, server will send heart beat and client (who subscribered) will be received this message. In the message, I included the root IP of server
Everything will be OK if this server had only 1 network card (NIC).
But in the case, server have 2 or more network cards. I met issue.
In the message is received by client, the IP of server not right.
I used InetAddress.getLocalHost().getHostAddress() to get to root IP and I known it wrong in this case server had 2 NICs
So can you give me some advise, how I can get right IP here?
Some guys said we can refer "the socket being used for getting right IP". Do you know how we can get it?
First of all I don't understand why you need IP address, If you think of implementing heartbeat, its not required, If you have used org.hornetq.jms.client.HornetQJMSConnectionFactory It automatically does heartbeat check. And If you have two servers and want to differentiate between servers, use a clientId and send it in message header and while listening you can select message based on the clientId or other approach use sync jms calls.
I have what appears to be a race condition related to losing responses coming from my heroku web service.
The heroku router delivers the request to the web service, the web service processes the request and returns a response, but in the interim the heroku router fails the request, either due to client (interrupt) or backend timeout.
The problem is that the web service request processing changed state on the backend and expected to send the state change to the client in the body of the response. The response never gets to the client, therefore the state change is lost forever.
The state change in my case happens to be the delivery and removal of a message from a RabbitMQ message queue. The web service request handler pops the request from the RabbitMQ queue, but it fails to reach the client and is never heard of again.
I could implement my own client-based message ACK system to mitigate this. However, I suspect that some of you might have a better solution regarding how to deal with ensuring that the responses get to the client. Is there any callback that I can use on my web service to determine if the response was lost? FWIW my web service is a JAX-RS service running embedded Jetty.
Thanks!
Here is the thing:
We've implemented a C++ RESTful API Server, with built-in HTTP parser and no standard HTTP server like apache or anything of the kind
It has been in use for several months in Amazon structure, using both plain and SSL communications, and no problems have been identified, related to Amazon infra-structure
We are deploying our first backend using Amazon ELB
Amazon ELB has a customizable health check system but also as an automatic one, as stated here
We've found no documentation of what data is sent by the health check system
The backend simple hangs on the socket read instruction and, eventually, the connection is closed
I'm not looking for a solution for the problem since the backend is not based on a standard web server, just if someone knows what kind of message is being sent by the ELB health check system, since we've found no documentation about this, anywhere.
Help is much appreciated. Thank you.
Amazon ELB has a customizable health check system but also as an
automatic one, as stated here
With customizable you are presumably referring to the health check configurable via the AWS Management Console (see Configure Health Check Settings) or via the API (see ConfigureHealthCheck).
The requirements to pass health checks configured this way are outlined in field Target of the HealthCheck data type documentation:
Specifies the instance being checked. The protocol is either TCP,
HTTP, HTTPS, or SSL. The range of valid ports is one (1) through
65535.
Note
TCP is the default, specified as a TCP: port pair, for example
"TCP:5000". In this case a healthcheck simply attempts to open a TCP
connection to the instance on the specified port. Failure to connect
within the configured timeout is considered unhealthy.
SSL is also specified as SSL: port pair, for example, SSL:5000.
For HTTP or HTTPS protocol, the situation is different. You have to
include a ping path in the string. HTTP is specified as a
HTTP:port;/;PathToPing; grouping, for example
"HTTP:80/weather/us/wa/seattle". In this case, a HTTP GET request is
issued to the instance on the given port and path. Any answer other
than "200 OK" within the timeout period is considered unhealthy.
The total length of the HTTP ping target needs to be 1024 16-bit
Unicode characters or less.
[emphasis mine]
With automatic you are presumably referring to the health check described in paragraph Cause within Why is the health check URL different from the URL displayed in API and Console?:
In addition to the health check you configure for your load balancer,
a second health check is performed by the service to protect against
potential side-effects caused by instances being terminated without
being deregistered. To perform this check, the load balancer opens a
TCP connection on the same port that the health check is configured to
use, and then closes the connection after the health check is
completed. [emphasis mine]
The paragraph Solution clarifies the payload being zero here, i.e. it is similar to the non HTTP/HTTPS method described for the configurable health check above:
This extra health check does not affect the performance of your
application because it is not sending any data to your back-end
instances. You cannot disable or turn off this health check.
Summary / Solution
Assuming your RESTful API Server, with built-in HTTP parser is supposed to serve HTTP only indeed, you will need to handle two health checks:
The first one you configured yourself as a HTTP:port;/;PathToPing - you'll receive a HTTP GET request and must answer with 200 OK within the specified timeout period to be considered healthy.
The second one configured automatically by the service - it will open a TCP connection on the HTTP port configured above, won't send any data, and then closes the connection after the health check is completed.
In conclusion it seems that your server might be behaving perfectly fine already and you are just irritated by the 2nd health check's behavior - does ELB actually consider your server to be unhealthy?
As far as I know it's just an HTTP GET request looking for a 200 OK http response.