Emran, Clebert,
Since you both proposed this feature, can you try to give an example of a real use case where it might be needed? This
would then help us define the feature in more detail.
Also...
>>
>> [Nigel] This isn't about how long we wait for an individual message, it's how long the JMS provider should wait for the a full
>> batch of messages to arrive on the destination. If the timeout is reached, it delivers whatever it has so far.
>>
>
> [Emran] I see an issue here. If the JMS provider attaches the timeout to the destination, I think we will not be able to handle
> the cases where multiple consumers specifying multiple timeout values. IMHO, JMS provider should keep pushing messages
> to the "consumer objects" on the server side, and these "consumer objects" should apply the timeout and further push the
> messages to the client-side consumer. The example scenarios that you mentioned below would still hold good with this.
I agree that it is desirable that the timeout (and the batch size) should be a property of the consumer, not the
destination itself.
Many JMS providers, for performance reasons, do "push" multiple messages to the client, where they are cached prior to
calling onMessage() (or a call to receive()). The JMS spec doesn't neither mandates this or forbids it. When devising a
new API for batch delivery we might want to consider how it might work with providers that do this, and those which do not.
>>>
>>>> [Nigel] 3. I note you say that auto-ack would ack them all in a single batch. Were
>>>> you expecting client-ack and local transactions to behave as now (so a call
>>>> to acknowledge() or commit() would ack or commit all the messages delivered
>>>> by the session, not just those in the batch), or were you thinking of
>>>> something different?
>>>
>
> [Emran] If we are sending all acks in a single batch, we might have to add more clarification regarding duplicate delivery of
> messages to the consumers (section 4.4.12). Right now this section says that, since the client is not in direct control
> of acks with AUTO_ACK, the last message consumed by the session could get redelivered (due to failures). With batch
> processing, the whole batch could get redelivered. We might have to clarify this.
Yes, good point. Thanks for pointing that out.
Nigel