Thanks for the info @anish. I’ll consider some options to maybe enable this in the future and talk to the team about potentially getting it added to the roadmap. That said, for now let’s consider the 2 mechanisms available to us to scale up the number of consumers.
Mechanism 1: The concurrency config on the binding. You’ll have to do some testing with your app to find the most efficient default, which will depend on your business logic, resources available to your Cloud Stream microservices, etc. This might be 2, 10 or something else depending on what you’re trying to do.
Mechanism 2: Scale instances of the app. As long as you specify a group on your bindings config to say that you’re using a Consumer Group then it will be consuming from a non-exclusive (by default) durable queue in Solace. Then if you’re deploying in a Kubernetes or some cloud environment can you scale up instances of your Cloud Stream microservice.
Hopefully a mix of those 2 mechanisms will work for you!