Man.yeah.. we discussed that back in.2011.. can't believe it's that long..
that makes me feel old :)
I like the possibility of being arrays... and I agree with your idea:
This one here definitely hits the mark of what I'm thinking:
@BatchConfig(maxBatchSize=100, batchTimeout=10000);
@JMSListener(lookup="java:global/Trades", type=JMSListener.Type.QUEUE)
public void processTrades(TextMessage[] tradeMessages,
@MessageHeader(Header.JMSCorrelationID) String[] correlationIds){
...
}
Just one minor thing: maybe we should have default values for BatchConfig
in case it's not present, or that should represent a deployment error?
On Thu, Aug 27, 2015 at 12:45 PM, Nigel Deakin <nigel.deakin_at_oracle.com>
wrote:
> On 27/08/2015 16:11, Clebert Suconic wrote:
>
>>
>> On Thu, Aug 27, 2015 at 10:37 AM, Nigel Deakin <nigel.deakin_at_oracle.com
>> <mailto:nigel.deakin_at_oracle.com>> wrote:
>>
>> Hi Clebert,
>>
>> We should definitely discuss how the JMS 2.0 proposals proposals for
>> batch delivery (since deferred) might work with
>> the new-style MDBs and listener beans.
>>
>> As you know, MDB users can turn off XA transactions using the
>> @TransactionManagement annotation, and can remove the
>> number of network round-trips using an acknowledgement mode of
>> DUPS_OK. Why is this not sufficient?
>>
>>
>> Because users want to have the messages and their Database operations in
>> transaction.
>> I have seen this pattern since my days of consultant.
>>
>> This goes beyond my JBoss. I'm not concerned about any specific usecase
>> from JBoss, but from what I see from users doing
>> on day by day with their messaging systems.
>>
>> DupsOK is ok, but that doesn't guarantee the semantic these users have.
>>
>>
>> Or do you have a specific need to have XA transactions that cover
>> multiple messages?
>>
>>
>>
>> From what I see, EE users will want to have async messages, but will
>> need transactions.. the easiest way to do XA
>> Transactions between JMS and Databases are through EE... for that reason,
>> users are *over-using* MDBs... and XA transaction
>>
>> And that's limiting any improvements done by any messaging provider.
>>
>> A few handful users will write standalone application to batch things
>> properly...
>>
>>
>> So, I think we really should propose a way to batch things through MDBs.
>> At least these users would take full advantage
>> of asynchronous message systems and still do transactions.
>>
>>
> OK, thanks. So the user *does* want XA transactions. They just don't want
> every single message to be in a separate transaction.
>
> As you will of course remember, you proposed "batch delivery" for JMS 2.0.
> This was a way of passing an array (or whatever) of messages in the same
> onMessage() call.
>
> (Incidentally, another approach might be to provide a mechanism for
> grouping multiple container-managed transaction MDB onMessage() calls
> together under a single transaction. I know Weblogic has a proprietary
> feature like this, others may too.)
>
> I went back to look at the ideas we discussed for batch message delivery.
> This was back in December 2011! The basic idea was to have a new
> BatchMessageListener interface, which defined a method onMessages.
>
> public interface BatchMessageListener {
> void onMessages(Message[] messages);
> }
>
> During that discussion we decided that the application needed to be able
> to specify maxBatchSize and batchTimeout:
>
> * maxBatchSize - The maximum batch size that should be used. Must be
> greater than zero.
>
> * batchTimeout - The batch timeout in milliseconds. A value of zero means
> no timeout is required The JMS provider may override the specified timeout
> with a shorter value.
>
> Now it's JMS 2.1, and we're discussing my proposals that JMS MDBs don't
> need to implement a fixed interface and can define their own callback
> methods.
>
> I've already proposed that a callback method could be defined with two
> parameters, the first of which was a TextMessage, and the second was the
> JMSCorrelationID of that message.
>
> @JMSListener(lookup="java:global/Trades", type=JMSListener.Type.QUEUE)
> public void processTrade(TextMessage tradeMessage,
> @MessageHeader(Header.JMSCorrelationID) String correlationId){
> ...
> }
>
> An obvious extension would be to allow these parameters to be arrays:
>
> @JMSListener(lookup="java:global/Trades", type=JMSListener.Type.QUEUE)
> public void processTrades(TextMessage[] tradeMessages,
> @MessageHeader(Header.JMSCorrelationID) String[] correlationIds){
> ...
> }
>
> We'd need to define some new annotations to allow maxBatchSize and
> batchTimeout to be specified. Perhaps:
>
> @BatchConfig(maxBatchSize=100, batchTimeout=10000);
> @JMSListener(lookup="java:global/Trades", type=JMSListener.Type.QUEUE)
> public void processTrades(TextMessage[] tradeMessages,
> @MessageHeader(Header.JMSCorrelationID) String[] correlationIds){
> ...
> }
>
> No doubt there are other possibilities, and I know arrays are a bit
> old-fashioned, but I hope this gives an idea.
>
> Is this on the right track, Clebert? If so I'll write this up in a bit
> more detail.
>
> Nigel
>
>
>
--
Clebert Suconic