Below...
On 28/07/2011 13:43, Graham Wallis wrote:
>
>
> Just a couple of thoughts from me:
>
>
> Clebert Suconic<clebert.suconic_at_gmail.com> wrote on 27/07/2011 16:26:46:
>
>> From: Clebert Suconic<clebert.suconic_at_gmail.com>
>> To: jsr343-experts_at_jms-spec.java.net
>> Date: 27/07/2011 16:26
>> Subject: [jsr343-experts] Re: Batch processing...
>>
>> I will answer with what is IMHO:
>>
>>> 1a. If the destination contains, say, 20 messages, does it deliver 20
>>> messages or does it wait for a further 30 to arrive before calling
>>> onMessages()?
>>>
>>
>> The implementation would be able to make a callback to the server and
>> verify if the server's destination is empty, and flush it case it's
>> empty.
>>
>> We could add support for an optional timeout argument. Say, you would
>> flush if the client buffer didn't get a message in X milliseconds (or
>> seconds).
>
> The use of a timeout is what I think most people would expect for this. It
> has the disadvantage of being another thing to configure, but there are
> systems that have batch read (with configurable sizes and timeouts)
> although the MDB is driven for each individual message.
I can't see how this would work without a timeout. With no timeout the provider could behave just like the existing,
single, onMessage().
>>
>>> 1b. If the destination is initially empty, and messages are being
> addded to
>>> the destination at 10 messages every second, how many messages
> aredelivered
>>> in each batch?
>>>
>>
>> Same as 1a. If we add the support for a timeout it would be up to the
>> user what to do. Either flush the current buffer or wait it complete
>> with 50 messages.
>>
>>
>>> 2. Do you care whether these messages are consecutive? (if there were
> more
>>> than one consumer on the same queue then they might not be)
>>>
>>
>> I think we should keep the same semantics currently all the providers
>> (I know) have,. i.e. Messages are in order but not required to be
>> consecutive. (if more than one consumer on the queue). We just need to
>> keep the same semantic as we had with a single call to onMessage.
>>
>
> I think it's normal to consider multiple consumers (with the same selector)
> reading from the same queue as being "equivalent". Presumably if a pair of
> applications are using message groups then those should remain independent
> of batches.
I don't quite follow. What do you mean by the term "message groups"?
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?
>>
>> Same thing.. We are just merging several onMessage calls into a single
> call.
>>
>> That means this for client ACK:
>>
>> onMessage(Message[] messages)
>> {
>> messages[20].acknowledge(); // it would ack up to the message[20]
>> + anything already acked on the session.
>> }
>