Combining GoLang, NodeJS and Java JMS clients

rythmic

Hi,
We have Solace Appliances at our shop and for a particular VPN, we have a lot of JMS clients publishing to topics and consuming from persistent queues. Messages are also published with persistence. All topics only have Solace Queues as subscribers in order to secure this persistence and allow for consumer downtime.
We are thinking about adding existing NodeJS and GoLang based clients (which currently integrate with each other through RabbitMQ) into the described solace environment.
In your overview graphics I see Go clients communicating through MQTT which I don't think supports the setup described above. But there also seem to be AMQP 1.0 bindings available for Go. Can that work with the setup described? Is there any general advice on Migrating from RabbitMQ to Solace? We want to get rid of the RabbitMQ setup so it's not an option to shovel messages, we already have our rabbitmq-2-solace adapter in place for that.

marc

Hi @rythmic,
With Go the simplest API would be MQTT. If you used QoS1 Consumers the broker will actually bind the consumer to a queue with the defined topic subscrption(s) under the covers. This would allow you to follow the pattern of publish to topics and subscribe to queues as you are doing with your JMS apps.

A few things to be aware of with our current MQTT impl:
1. If "MqttConnectOptions.cleanSession" is true your consumer will bind to a temporary queue. If it's false it will bind to a durable queue. You'd want the latter if you can't lose messages when your app is offline.
2. MQTT Consumers currently only support exclusive queues so you can only have one consumer reading from the queue at a time. (This restricts the ability to scale up multiple instances of your app)
3. There is a currently a restriction with MQTT where you can only have 1 consumer / queue per Solace Session. Meaning if your app needs to listen on multiple queues you have to create multiple sessions (which is not the case with other APIs).

If you can work with those restrictions I'd recommend going with MQTT over AMQP as the AMQP apis tend to be more complex. That said, if you do use AMQP with Go please let us know what the experience is like as I haven't heard from anyone who has done so. If you can't work with those restrictions then yes, AMQP should not have the same restrictions as above.

Hope that helps!

marc

Also note that we have this persistence with queues MQTT tutorial available. While it's using Java, the MQTT concepts should translate directly to using the Go Paho API.