Try PubSub+

Dynamically chaging the concurrency value for spring cloud stream

Hi ,
Is there a way to dynamically changing this "concurrency" value without application down? I am using solace and spring cloud stream for listining message . There is a need to reduce/increase number of consumer on demand to manage application throughput.

Comments

  • marcmarc Member, Administrator, Moderator, Employee Posts: 298 admin
    edited February 18

    Hi @anish,
    Great question! From googling I'm not sure if the framework supports it. Have you tried changing the configuration via spring boot actuator or via JMX endpoints?

  • anishanish Member Posts: 6

    @marc - i have checked but refresh would not work as the "concurrency" parameter are not in @refreshscope . So what ever bean got created during application deployment , not getting refreshed.

  • marcmarc Member, Administrator, Moderator, Employee Posts: 298 admin

    Great point @anish, so it sounds like the answer is no for now but I'll let you know if I come up with a way. Because the spring.cloud.stream.bindings.<BINDING-NAME>.consumer.concurrency config is exposed at the framework level (and not the Solace binder) can I get you to open an enhancement at the framework level on their github repo?

    If you open it then I'll upvote it and bring it to the attention of the Spring team behind the scenes as well :)

  • anishanish Member Posts: 6

    @marc i got the below response https://stackoverflow.com/questions/66305243/support-for-concurrency-parameter-refresh-on-the-fly-spring-cloud-stream/66318141#66318141
    Not all binders/technologies support that, so it's not available at the SCSt level; if you are using the RabbitMQ binder, you can customize the container properties using a ListenerContainerCustomizer bean.

  • marcmarc Member, Administrator, Moderator, Employee Posts: 298 admin

    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!

  • anishanish Member Posts: 6

    @marc thanks for the giving update

  • AaronAaron Member, Moderator, Employee Posts: 169 Solace Employee

    So probably Kafka doesn't support it dynamically (makes sense, would cause a rebalance), so that's maybe why Spring doesn't want to support it at the framework..? Although if enough technologies push for it (e.g. Rabbit & Solace) then they wouldn't have to use custom extensions.

Sign In or Register to comment.