🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Solace health checks
Hi,
I'm currently implementing health checks endpoints for my Asp.Net Core services. Most of them are connected to Solace, so I'd like to have one of the health checks to check if service can be connected to VPN. What would be the best/"cheap" way of doing this? Creating Solace Session each time and trying to connect? My main concern is that this healthcheck will be called quite often, so not sure if opening and closing new session every 30 secs is a good idea.
Answers
-
Hi @anton, there is a health check service on the broker. This was designed for load balancers. Will that help?
0 -
Hi @TomF . Thanks, but this is to check if broker is alive. What I want to check is if my service can actually connect to Broken successfully. Most of my services have dependencies on Sql Server and Solace, so idea is to have 2 health check for readiness probe that will check if connections can be successfully established to Sql Server and Solace.
0 -
Ah, so the check is not that the broker is alive, but that the application can connect.
Have you thought about leaving the connection up all the time? That's the ultimate connection probe :-) If the number of services is small compared to the broker connection tier (say 20 services on a 100 tier broker or 200 services on a 1k broker), it will be simpler more robust, and easier to manage.
0 -
@Anton, what I really meant was open your connection to the broker to check that the connection can be made.
_Keep the connection_. If there are any connection problems, the API will tell you! This gives you an easy way to track the connection health, because the APIs do most of that work for you.
When you need to start consuming or publishing, _use the same connection_.
Openning a connection is quite resource intensive, especially if it's an encrypted connection, but unless you are opening and closing over a hundred connection a second it's unlikely to cause a problem. Personally, I would be more worried about the complexity of the code I'm using and how robust it is. Using a single connection, you'll get advance notification of a connection problem as soon as it happens, rather than waiting for the 30 second health check, and what's more, there's very little code needed because most of it is already implemented in the API.
0 -
To add to Tom's point, depending on the API you are using you can configure callbacks on your session/messaging service incase any interruption happens. So for example, if you are using the PubSub+ Python API you simple register the service interruption listener to your messaging service and that is your health check for "the application can connect"
0
