explaining what I meant on my previous email....
Someone asked the message grouping to be handled like the follwowing:
Imaging the Resource Adapter implementation:
Tx.begin(); << pseudo-language:
for (int i = 0 ; i < 1000; i++) {
MDB.callbackmethod(consumer.receive(TIMEOUT));
}
TX.commit();
And I don't think we should do that.. that could be easily a specific
AS implementation without requiring any changes to the Spec.
That's just to say I'm +1 for your proposal Nigel!
On Mon, Oct 12, 2015 at 11:21 AM, Clebert Suconic
<clebert.suconic_at_gmail.com> wrote:
> 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
--
Clebert Suconic