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.
>
> > 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.
>
> > 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.
> }