I was a bit shocked at discovering it was 2011 too :-)
I'll think about this a bit more and propose something as an add-on the existing JMS MDB proposals. The @BatchConfig
annotation was just off the top of my head.
I think we should define some default values for batchSize and batchTimeout . Perhaps batchSize=1 should be the default
(in which case batchTimeout is ignored).
Before we go deeply into this, I'd like to mention that Weblogic has a MDB feature for batching multiple messages in the
same transaction. This is described here:
https://docs.oracle.com/cd/E24329_01/web.1211/e24977/batching.htm#WLMDB1384
This works by deferring the transaction commit after a defined number of messages have been received.
My colleagues on the Oracle Weblogic team tell me that this can offer better throughput as it allows the earlier
messages to be processed whilst waiting for subsequent messages to arrive, rather than saving them up and delivering
them all in one go. Do you think a similar approach has any merit?
Nigel
On 27/08/2015 17:54, Clebert Suconic wrote:
> 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 <mailto: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>
> <mailto: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