Maybe that's just a detail, but I thought about this being a different
class. Maybe BatchMessageListener...
With that, you would be able to set a batchListener to a Consumer.
consumer.setBatchListener(batchListenerInstance, size, timeout);
or
// it could use the annotations to get the two other parameters.
consumer.setBatchListener(batchListener);
just to keep the APi compatible with previous applications.
On Fri, Jul 29, 2011 at 1:19 PM, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> (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
>
>
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com