Reputation: 7788
I'm using ActiveMQ fail-over e.g.
failover:(tcp://host1:61616,tcp://host2:61616)
I would like to alert when neither host1 nor host2 are available.
If the application has already connected to a broker, you can detect when it fails-over via a TransportListener. The same is not possible during initial connection. It will just hang, repeatedly retrying each broker. That's the desired behaviour, in that I want it to continue to try to connect, however I also want to be notified that it is having trouble so that I can alert, and someone can look into it.
One solution is to use
failover:(tcp://host1:61616,tcp://host2:61616)?startupMaxReconnectAttempts=1
This means it will try each host and then throw an exception, which my application can handle by alerting and then trying to connect again. This is not ideal, as my application then has to effectively duplicate the ActiveMQ reconnection logic.
Is there a better way of detecting broker problems on initial connection?
Upvotes: 3
Views: 1414
Reputation:
Short answer: no, there is no way to know from client (application) startup perspective.
Long answer: As an application, you will only know when: you have no broker available at all (through the startupMaxReconnectAttempts), or when you switch from one broker to the other. This is the expected and desired behavior, since the whole point of the failover mechanism is to hide all this from the consumer.
There are probably some ways around (using dynamic network of brokers for eg) but that would require more logic than the solution you propose.
I would think you are trying to solve a problem with the wrong tool: using failover mechanism (with max reconnect and a proper timeout) would just ensure you get notified when something goes really wrong (no broker available at all). The "health" or "connectivity" of the other brokers need a separate mechanism (at system level -use a monitoring tool- or at application level -develop a little mechanism to do a keep alive to all the brokers in the uri list)
Upvotes: 3