I'm happy with that proposal...
It keeps it simple.... just a simple @Batch annotation would be what
we require... The timeout would be always in milliseconds?
One parentheses.. someone (from WebLogic) asked us to support batching
on the transactional background. I don't think the spec needs to be
changed for that... that would be a simple application server
feature... and it would complicate the specification, where we would
have to define transactional scenarios... etc. If we keep this simple
an array of messages would be an easy thing to be defined and easier
to understand...
On Mon, Oct 12, 2015 at 11:03 AM, Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
>>> 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
>
>
>
>
>
>
>
--
Clebert Suconic