>> On 06/10/2015 17:42, Clebert Suconic wrote:
>>> I think we should prioritize Batching for next Draft... as I believe there will be
>>> some feedback from the community.
> On Tue, Oct 6, 2015 at 12:54 PM, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
>> I'm very happy to talk about batching next.
On 06/10/2015 18:08, Clebert Suconic wrote:
> Great... If needed we could make a google hangout/ Bluejeans session
> or any video conf service the subject at some point. Maybe it's more
> productive than Asynchronous email :)
I'm happy to take up that suggestion and organise a conference call (either Google Hangouts or the system we use here is
which is Zoom which may allow more participants). But it would be worth me writing up a proposal which we can discuss.
The proposal we discussed for JMS 2.0 but dropped is described in
https://java.net/jira/browse/JMS_SPEC-36
We dropped this because the API was getting too complicated, and we agreed we should wait until we had user-configurable
callback methods. Now in JMS 2.1 we are close to having these for MDBs, though not for Java SE applications.
If we simply took the message batching concepts we discussed for JMS 2.0 and tried to support them using JMS 2.1-style
JMS MDBs, we could have something like this:
@MessageDriven
public class MyFlexibleMDB {
@JMSQueueListener( destinationLookup="java:global/myQueue")
public void myMessageCallback( @Batch(maxSize=10,timeout=1000) Message[] messages) {
...
}
}
We would allow the callback method to be an array of Message objects (or subtypes thereof) or perhaps an array of
allowed message body types.
The JMS provider/application server would then assemble messages into batches and deliver them in a single method call.
The @Batch annotation would allow the following settings to be configured:
* 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. Default is 1.
* 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. We'd probably want to
define a suitable default (or allow app servers to define it).
Any quick comments on this? What other things should we consider?
Nigel