Clebert,
This was on my list (both you and Emran suggested it) in my "priorities so far" email. But I haven't created a JIRA
issue for it. Let's discuss what this feature is now and I'll create a JIRA of rit.
Before considering API, can we confirm what this feature would allow?
I think you are asking for an enhancement to the way in which messages are delivered *asynchronously* to message listener.
Currently messages are delivered on-at-a-time by calling onMessage(Message message),
You are proposing that the application may specify that messages should be delivered in "batches" of, say, 50 messages.
These 50 messages would then be delivered at the same time in a single call to a new onMessages(Message[] messages)
callback.
A few questions and comments:
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()?
1b. If the destination is initially empty, and messages are being addded to the destination at 10 messages every second,
how many messages are delivered in each batch?
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)
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?
Nigel
On 26/07/2011 21:30, Clebert Suconic wrote:
> Did we add a JIRA or discussed this before? I lost track of it...
>
>
> It would be nice to have something like this:
>
>
>
> On a MessageConsumer
>
>
> @SomeAnnotation(batchSize=50)
> public void onMessage(Message[] messages)
>
>
>
> or on the Consumer...
>
>
> setBatchListener(lMessageListener, batchSize);
>
>
>
> Maybe we would be able to extend this to MDBs at some point.
>
> If using Auto-ACK, those messages would all be ACKed in a single batch.
>
> When MDB extends this, we could have MDBs adding transaction support.
>
>
>
>
> I'm proposing this because it's a common problem among message
> processing. When you have an event, you are forced to make a
> transaction for each message you receive.
>
>
> Users would be able to do optimizations like this:
>
>
> public void onmessage(Message[] messages)
> {
> Money ammount = new SomePseudoObjectMoney(); // whatever you wnat here
>
> for (Message msg : messages)
> {
> ammount.add(msg.getWhateverNumberProperty());
> }
>
>
> // you didn't need to make 100 updates here, a single update was fine!
> // and a single commit also.
> database.update(ammount);
>
> }
>
>
>
>
>
> It would be nice to have this as part of the spec, instead of being a
> proprietary extension.
>
>
> It would be a nice feature to JMS IMO.