Add batchReceiveTimeout in SimpleMessageListenerContainer

[laststem]

Expected Behavior

receiveTimeout is The maximum time to wait for each message.
If there is batchReceiveTimeout, the time while waiting for the entire batchSize can be applied not each message.

Current Behavior

There is no batchReceiveTimeout.
so, receiveTimeout applies to individual messages.. wait for batchSize*receiveTimeout amount of time in worst case.

[artembilan]

Sorry, the info you provide is not enough.
See doReceiveAndExecute(BlockingQueueConsumer consumer) logic in the SimpleMessageListenerContainer.
It really means that we would like to gather the whole batch before processing if you enable consumerBatchEnabled.
Therefore it feel natural to wait for each message for that receiveTimeout independently.
Otherwise we try to debatch a single message and break the loop.

I don't see how that extra new property can be helpful.

Please, elaborate.

[laststem]

@artembilan Thanks for reply. and sorry for not enough explanation.

If it is not a batchlistener or batchSize is 1, it is natural to wait for each message for receiveTimeout.

But if batchSize is 1000 and receiveTimeout is 1000ms and consumer.nextMessage(this.receiveTimeout) waits for (receiveTimeout-1)ms to retrieve the message, the total waiting time(1000 * 1000ms) is too harsh.

This is that if messages are provided to BlockingQueueConsumer.queue every (receiveTimeout-1)ms.
As a result, in this situation, it waits for receiveTimeout to fetch one message, and this is repeated for as many times as batchSize, so the previously fetched messages have no choice but to wait a long time.

So, batchReceiveTimeout it can limit the time it waits to fill batchSize.
while accumulating waiting time through consumer.nextMessage(this.receiveTimeout), if batchReceiveTimeout is exceeded, the loop is stopped and executeWithList is called.

[artembilan]

OK. So, your request is to emit the gathered batch not after the whole number, but when some timeout threshold is reached.
Like you said: we wait for each message for that receiveTimeout, but then before the next attempt we consult with this new batchReceiveTimeout and short-circuit if any.

If I understand your correctly, feel free to contribute the fix and I'm gladly review it: https://github.com/spring-projects/spring-amqp/blob/main/CONTRIBUTING.adoc