[FEATURE REQ] Configration consistency with spring cloud stream

[dhananjay12]

[We use spring cloud stream abstraction in our codebase and the relevant binders gets decided based on build/deployment. Binders we use - activemq, kafka, rabbit and recently started using azure-service-bus binders.

We noticed some differences wrt properties key (some missing) that been used. For example

1. Max concurrent messages client should process (introduced new servicebus layer and changed the name for concurrency and prefetch) ActiveMQ binder:

   spring:
   cloud:
   stream:
     bindings:
       renderChannelMessage:
         consumer:
           concurrency: 10
           prefetch: 1000

   ASB binder:

   spring:
   cloud:
   stream:
     servicebus:
       bindings:
         renderChannelMessage:
           consumer:
             max-concurrent-calls: 10
             prefetch-count: 1000

2. Retry mechanism configuration is completely different and there are 2 types- Exponential, Fixed ActiveMQ binder:

   spring:
   cloud:
   stream:
     default:
       consumer:
         backOffInitialInterval: 10000
         backOffMaxInterval: 40000
         backOffMultiplier: 2.0

   ASB binder:

   spring:
   cloud:
   azure:
     retry:
       mode: exponential
       exponential:
         max-retries: 5
         base-delay: PT2S
         max-delay: PT60S

3. Global configuration for consumer is not found for ASB (needs more investigation) which includes concurrency and prefetch ActiveMQ binder:

   spring:
   cloud:
   stream:
     default:
       consumer:
         concurrency: 10
         prefetch: 1000

   ASB binder:

   N/A

4. Group configuration is still under investigation in how to make it work because not clear how this work for ASB ActiveMQ binder:

   spring:
   cloud:
   stream:
     bindings:
       renderChannelMessage:
         group: ceo-group

   ASB binder:

   spring:
   cloud:
   stream:
     bindings:
       renderChannelMessage:
         group: <uuid-id-generated-dynamically-for-each-env>

NOTE: the 4th issue is really a struggle as we have to get the ID and then update the relevant services with it. Redo the same if its incase of re-creation of topics.

Describe the solution you'd like I would like a consistent naming convention with Spring. Dealing with properties while using azure-binders can be a bit of a struggle due to the differences in property names. Switching among other binders is easy since the same property keys work for all, but if the deployment uses azure-service-binders, one has to find the equivalent properties.

Additional context We understand that there are two similar services like eventhubs and servicebus that require different keys. However, the last part of the key, such as concurrency vs max-concurrent-calls or prefetch vs prefetch-count, could be made similar. Spring allows two properties to be mapped to the same key without the need to change the existing key.

Also, for values like in spring.cloud.stream.bindings.renderChannelMessage.group, friendly names should be allowed, which get automatically mapped.

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• [x] Description Added
• [x] Expected solution specified

[Netyyyy]

Hi @dhananjay12 Thank you for reporting this issue. We have received your submission and will take it into consideration. We appreciate your input and will review this matter as soon as possible. Please feel free to provide any additional information or context that you think may be helpful. We'll keep you updated on the progress of our review. Thank you for your contribution to improving our project.

[saragluna]

I think this should be treated as a bug in the Spring Cloud Azure Stream Binder to fix, @dhananjay12 could you elaborate more on the 4th? How does this group act in your application?

[dhananjay12]

Hi @saragluna

For the 4th item , we are not facing this with the latest version of the binder, so it can be marked as resolved.

For rest of them which involves consistancy with the spring cloud stream names, its docs can be reffered from here - https://docs.spring.io/spring-cloud-stream/docs/current/reference/html/spring-cloud-stream.html#spring-cloud-stream-reference

May be map 2 configuration to the same class variable to maintain backwar compatibility?