(This is the batch processing thread)
I have now logged this in JIRA
http://java.net/jira/browse/JMS_SPEC-36
Here's what I wrote:
"It is proposed that the JMS API be extended to allow messages to be delivered to a MessageListener in batches rather
than individually as in JMS 1.1.
Currently, messages are delivered asynchronously by calling the {{javax.jms.MessageListener}} method {{onMessage(Message
message)}}.
However some applications could process messages more efficiently if they were delivered in batches, perhaps by calling
a new {{javax.jms.MessageListener}} method {{onMessages(Message[] messages)}}.
It would be necessary to configure this by adding two new methods to {{javax.jms.MessageConsumer}}:
* {{setBatchSize(int batchSize)}} If set to a value greater than zero, messages will be delivered in batches of up to
{{batchSize}} messages. The actual batch size used may be smaller than this, but it may never be larger.
* {{setBatchTimeout(long batchTimeOut}} The maximum number of milliseconds that the JMS provider may defer message
delivery for in order to assemble a batch of messages that is as large as possible but no larger than the batch size.
Acknowledgement:
* If auto-acknowledgement was being used, all messages in the batch would be acknowledged together. Section 4.4.12
"Duplicate Delivery of Messages" of the JMS 1.1 spec explains that when auto-acknowledgement is being used, if a failure
occurs, clients can't know for sure whether the message has been successfully acknowledged, and so the last consumed
message may may be redelivered. This section would need to be extended to state that in the case of batch delivery, if a
failure occurs, all messages in the last batch may be redelivered.
* If dups-ok acknowledgement was being used, message acknowledgement would follow existing semantics.
* If client acknowledgement, or local or global transactions, were being used then message acknowledgement would follow
existing semantics, which is that a call to acknowledge(), or the commit of the transaction, would acknowledge all
unacknowledged messages delivered by the session."
See also below...
On 29/07/2011 16:34, Clebert Suconic wrote:
> Comments bellow:
>> With no timeout then we will get something like:
>>
>> (no wait)
>> onMessages(first 20 messages)
>> (100ms elapses)
>> onMessages(1 message)
>> (100ms elapses)
>> onMessages(1 message)
>> (100ms elapses)
>> onMessages(1 message)
>> (100ms elapses)
>> onMessages(1 message)
>> etc etc
>>
>> You'll see that this could end up with no batching at all.
>>
>
>
> I agree the timeout is needed, but there are certain use cases where
> the user doesn't want a timeout.
>
> The user may want to process as soon as possible anything that's on
> the buffer. But on that case the user can just configure timeout = 0.
>
> The user may expect the message consumer being busy processing the
> messages. So, he configured the consumer to get anything that is on
> the buffer, and it was produced while the user was processing the last
> batch.
Yes, good point.
>
> It would be just a configuration option for the user.
>
> Most users will use a timeout, but some will prefer having a timeout.
>
> Like, on this real use case:
>
(snip>
That is very helpful. So the general idea is that messages should be delivered in batches because the onMessage() method
can process them more efficiently. So it doesn't matter if the batch size decreases when the rate of message delivery slows.
OK. As I mentioned above I've now logged this in JIRA.
>
> They can't use MDBs for this either. My expectation is that the EJB
> spec will get this as part of their spec as well.
If we added this to JMS we would definitely want to make it available to MDBs. Since the MDB spec isn't JMS you could
already implement this now by changing the JMS provider and JCA adapter but without making changes to the app server.
But we would want to standardize how this is configured in EJB 3.2.
> (Another subject is that the MDB API sucks.. it should be a single
> API.. or super class for JMS and EE IMO). But that's another story.
Indeed! As you know I'm trying to keep that topic separate.
Nigel