-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for multiple server URLs #215
Comments
A did a bit of extra digging and since we are also using node-amqp module, I found out that it allows for the 'host' property to be specified as an array. An array of URLs would be more flexible, but if you set up multiple RabbitMQ nodes using the same port, user and password, it would work (although it is harder to test locally since you cannot install two rabbitmq instances in localhost without using different port numbers). |
@dglozic you can submit a PR now :). |
I was searching around a bit and found that an alternative would be to stand up an HAProxy in front of RabbitMQ nodes and continue to use one virtual address. HAProxy would handle TCP proxying and health checks/failover. We will try that first. Or even LVS on our Linux VMs. The advantage of the client handling multiple URLs is that you don't add another single point of failure that you need a backup for :-). |
If you are on AWS, you can use ElasticLoadBalancer. |
It came across in my searches, although considering I work for IBM, I am most decidedly not on AWS :-). |
Yep, but that's something that might help lots of people too ;). |
Yes, sorry, I forgot am not the only one reading these issue :-). |
Here is something we just noticed: it would be great if we could specify more than one server URL in the client. This would be in context of an HA configuration (with, say, two RabbitMQ nodes configured in clustered mode). I checked Eclipse PAHO Java client and it already supports it via 'setServerURLs(String [] urls)'. I looked around a bit and setting up TCP load balancers in front of MQTT server array may be more trouble than its worth.
So maybe add it to the pile of ideas when you rewrite the client as hinted in issue 211 :-) ?
The text was updated successfully, but these errors were encountered: