Hi @samuel,
To your question having multiple queue destinations as a comma separated list does work and the app starts receiving messages from both the queues.
Thanks for that confirmation! I’ll have to try that out.
I was thinking that by adding the consumer property spring cloud stream partitioned: true, the binder will ensure that there is only one instance which is connected as primary to a particular queue, so that the load can be balanced among the available instances. I believe that’s how it works with spring cloud stream Kafka binder. The plan that I had was to deploy this micro service behind an auto scaling group, scaling the instances based on the cpu or memory utilisation of instance. So during a peak load if we have 5 queues, then we will end up having 5 instances of micro service each reading from a single queue. Similar to how consumer group and partitioning works with Kafka.
The Solace binder supports publish-subscribe and consumer groups patterns as defined by Spring Cloud Stream but does not support partitioning options in the framework so specifying partitioned: true won’t do anything for our binder. That said you can still do partitioning with solace topics as defined in @Aaron’s blog here. See the “Sticky Load-Balancing, or Keyed/Hashed Delivery” section. When doing that with Spring Cloud Stream I would recommend pre-creating your queues and having a separate app that manages the topic subscriptions on your queues. You can use Solace’s “On Behalf Of” functionality to do this (there is some solid content out there if you google that).