Dynamically chaging the concurrency value for spring cloud stream

anish
anish Member Posts: 6 ✭
in Connectors & Integrations #1

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

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 959 admin
    edited February 2021 #2

    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?

  • anish
    anish Member Posts: 6 ✭
    #3

    @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.

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 959 admin
    #4

    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 :)

  • anish
    anish Member Posts: 6 ✭
    #5

    @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.

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 959 admin
    #6

    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!

  • anish
    anish Member Posts: 6 ✭
    #7

    @marc thanks for the giving update

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 638 admin
    #8

    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.

Categories

This Month's Leaders

This Week's Leaders