Batch Message Splitting in Spring Cloud Function

[2tsumo-hitori]

Is your feature request related to a problem? Please describe.

• I am using Spring Cloud Stream with spring.cloud.function.definition, where my function returns a Collection type.
• Currently, when batch mode is enabled, all consumed messages are aggregated into a single List inside a single message.

This causes potential issues:

• Increased memory usage and processing overhead for subscribers when messages are large.
• No built-in way to split the messages within the function unless reactive programming is used.

Describe the solution you'd like

The goal is to introduce an option that allows batch messages to be split into individual messages.

• Add a boolean field (enableSplitting) to the FunctionInvocationWrapper class.
  • When set to true, the function will process each message individually instead of aggregating them into a single message.
  • When set to false (default), the current behavior remains unchanged.
• Additionally, I plan to create a related issue in Spring Cloud Stream to introduce a new splitMode option in ProducerProperties.
  • When enabled (true), List type messages will be published as individual messages.

Describe alternatives you've considered

1. Using Reactive Programming

   • Requires changes to function signatures and dependencies, making it difficult to apply universally.

2. Manually publishing individual messages using StreamBridge

   • Developers would need to manually iterate over List<Message<Object>> and publish each message separately.
   • This approach prevents the use of the functional interface (Function<T, R>), reducing code simplicity.

Additional context

• I also plan to open an issue in the Spring Cloud Stream repository, as it calls SimpleFunctionRegistry internally.

[olegz]

@2tsumo-hitori Sorry for getting back to this so late, but i have a question.
If you indeed want to process one message at the time, why would you choose batch option? The whole point of batching is to receive a batch or messages (e.g. List) not one at the time.
Especially when you mention Spring Cloud Stream where batching will occur much earlier (outside of spring-cloud-stream . . in spring-kafka or spring-amqp), so whatever memory and resources concerns you may have they will still be present eveb if you split the batch.
There may be other reasons and I am curious to know what they may be, but just wanted to share this with you

[2tsumo-hitori]

@olegz

Although I haven't looked deeply into Kafka's internal batch processing logic, I had the understanding that receiving messages in 'batch' units would generally incur less network overhead than receiving them as 'single' items multiple times. Considering this efficiency aspect, I thought it would be useful to have a feature where the consumer receives data in batch for network efficiency, but during application internal processing or producing, it could process or output them as single items depending on the logic's flexibility or specific needs.

Also, if the application server internal logic includes operations that could potentially cause blocking, such as external service calls, I believed receiving and processing messages in batches of a certain size could be advantageous in terms of overall throughput compared to single-item processing. (Of course, it's also possible to implement custom batch processing within the server using BlockingQueue etc., but my perspective was that it would be more convenient if this were abstracted at the framework level.)

In short, I chose 'batch consume' for network efficiency or the advantage in processing certain server logic, but I raised the need for this feature keeping in mind scenarios that require 'single message processing or flexible publishing' afterwards.

Thank you again for your replies, and for now, should I close it myself, or will you (or the person in charge) close it later?

[github-actions]

This issue has been stale for over 60 days