Geez, the silence is deafening on this one :-).
I hate to be the spoilsport, but how about just adding setBatchSize() to
the context/session/connection and leave it be for now (sort of like the
batch size concept in ORM tools like Hibernate)? It would basically be a
mode-switch of the existing APIs to start doing things in batches under
the hood. I know, it does not have the syntactic sugar, but it would
meet the need for performance optimization (provided that's the key
motivation for this feature)...
On 3/16/2012 8:46 AM, Nigel Deakin wrote:
> There have been some interesting discussions going on since last
> September over in the EJB EG about how MDBs could be made more general
> so they didn't need to implement MessageListener. It's worth going
> back and reading the "MDB Improvements" thread. However, as John
> notes, this looks like something that they will be deferring until
> Java EE 8.
>
> (Perhaps that's just as well given that we still haven't completed
> defining the annotations for injecting MessagingContexts)
>
> Here in JMS 2.0, the proposals below for message batching don't just
> apply to MDBs. They apply to Java SE applications as well. Even though
> we might want to support the use of CDI features when using JMS in a
> Java SE environment I think it unlikely that we would want to make it
> mandatory - at least as long as CDI is not part of Java SE. We
> certainly don't want to make new features such as message batching
> dependent on it. So we would still need to extend the existing
> "old-fashioned" async delivery API to support message batching.
>
> In addition, if we adopt the proposal for BatchMessage below then
> message batching would also be made available to synchronous
> consumers, and also perhaps when sending messages (if others join Rob
> in supporting this).
>
> Nevertheless, EG members need to consider whether adopting either
> proposal for message batching at this stage would prejudice any future
> simplifications along the lines Reza suggested.
>
> More comments would be welcome. Please indicate your preferences
>
> Question 1:
>
> A. We should keep the async batch message delivery feature using the
> BatchMessageListener API proposed in the Early Draft
> B. We should keep the async batch message delivery feature but use
> the BatchMessage API proposed below (Nigel, Rob)
> C. We should remove the async batch message delivery feature from JMS
> 2.0 and consider it again for Java EE 8. (Reza)
>
> Question 2:
>
> If option (B) is chosen, should we allow BatchMessages to be used by
> producer applications to send messages more efficiently? (Such
> BatchMessages would be broken into their constituent messages before
> they are added to the destination)
>
> Y (Rob)
> N
> Not sure: (Nigel)
>
> Question 3:
>
> if option (B) is chosen, should we extend it to support sync batch
> delivery as well as async?
>
> Y (Nigel, Rob)
> N:
> Not sure:
>
> Thanks,
>
> Nigel
>
> On 16/03/2012 01:53, John D. Ament wrote:
>> Not sure if it has been seen by all members of this EG, but the EJB
>> EG came back with a response from the platform team. it looks like
>> no changes to JCA are included in EE7, and changes to JCA would be
>> required to make these happen.
>>
>> On Thu, Mar 15, 2012 at 2:35 PM, Reza Rahman <reza_rahman_at_lycos.com
>> <mailto:reza_rahman_at_lycos.com>> wrote:
>>
>> I'd prefer we table this until the outdated interface-based
>> MDB/JMS message listener paradigm can be updated to something
>> modern/CDI-based/POJO-centric that supports something like this:
>>
>> @JmsListens
>> @JmsQueue("someQueue")
>> @JmsBatchSize(10)
>> public void processMessages (Message[] messages)
>>
>>
>> On 3/13/2012 3:02 PM, Nigel Deakin wrote:
>>
>> I'd like to resurrect our discussion on batch delivery.
>> This is http://java.net/jira/browse/JMS_SPEC-36
>>
>> As I mentioned earlier, and explicitly wrote in section A.2.
>> "Unresolved issues in the JMS 2.0 Early Draft", I'm concerned
>> that the API for batch delivery is rather more complicated
>> than it needs to be. Here is what I wrote:
>>
>> "The proposed API involves a new BatchMessageListener
>> interface. This has necessitated the addition of two new
>> methods on MessageConsumer and five additional methods on
>> MessagingContext.
>>
>> "In addition, since a MessageConsumer can only have a single
>> listener it has been necessary to explain how a call to
>> setBatchBatchListener would override a previous call to
>> setMessageListener. This is complicated and potentially
>> confusing.
>>
>> "One alternative way to allow messages to be delivered in
>> batches might be to invent a new message type, a
>> BatchMessage, which would contain an ordered collection of
>> normal Message objects. This would allow batches of messages
>> to be delivered to a normal MessageListener and so remove the
>> need for a separate BatchMessageListener interface. It would
>> also allow batch delivery to synchronous consumers."
>>
>> Another advantage of replacing BatchMessageListener with
>> BatchMessage is that it would avoid the need to extend
>> resource adapters and MDB code to support the new listener
>> interface.
>>
>> I'd now like to take this new idea further. The main change
>> is that we would drop the new BatchMessageListener interface
>> with its method onMessages(Message[] messages). Instead the
>> existing MessageListener interface would be used with its
>> existing method onMessage(Message message). When the JMS
>> server wants to deliver a batch of messages to the consumer
>> it would create a new type of message, a
>> javax.jms.BatchMessage, load it up with a batch-worth of
>> messages, and then deliver it to the MessageListener in the
>> usual way.
>>
>> I've sketched out below what the new API might look like.
>> Before I work this through in detail, I'd like to invite
>> feedback on various points of principle:
>>
>> ==================================================================================
>>
>>
>> QUESTIONS
>>
>> 1. Which is better, using a BatchMessageListener or allowing
>> the server to create BatchMessage objects?
>>
>> 2. I'm currently suggesting that BatchMessage objects would
>> never be created by the application, They would simply be a
>> convenient container object that the JMS provider could use
>> when delivering batches of messages. However we could if we
>> wanted allow the producer client to create them and use them
>> to send batches of messages to the server, which would then
>> break them down into their constituent messages before adding
>> to the destination. Would this have any benefit?
>>
>> 3. Should we take advantage of BatchMessage objects to allow
>> the server to deliver messages in batches to a synchronous
>> consumer?
>>
>> ==================================================================================
>>
>>
>> SUMMARY OF PROPOSAL
>>
>> THE NEW BatchMessage CLASS
>>
>> /** An <CODE>BatchMessage</CODE> object is a special type of
>> message which can be
>> * created by the JMS provider and used to deliver an ordered
>> batch of ordinary
>> * messages to a consumer. It inherits from the
>> <CODE>Message</CODE> interface
>> * and adds methods to allow the individual messages to be
>> extracted.
>> *
>> * Note that this message type is created by the JMS
>> provider, not by
>> * the application, and therefore only provides public methods to
>> * extract messages, not to set them.
>> *
>> * @see javax.jms.ObjectMessage
>> * @see javax.jms.BytesMessage
>> * @see javax.jms.MapMessage
>> * @see javax.jms.Message
>> * @see javax.jms.StreamMessage
>> * @see javax.jms.TextMessage
>> */
>>
>> public interface BatchMessage extends Message {
>>
>> /**
>> * returns the number of messages in this BatchMessage
>> *
>> * @return the number of messages in this BatchMessage
>> *
>> * @throws JMSException if the JMS provider fails to get
>> the size due to some internal error
>> */
>> int size() throws JMSException;
>>
>> /**
>> * returns the Message at the specified position in the batch
>> * @param index index of the Messagr to return
>> *
>> * @return the Message at the specified position in the batch
>> *
>> * @throws JMSException if the JMS provider fails to get
>> the Message due to some internal error
>> */
>> Message get(int index) throws JMSException;
>> }
>>
>> NEW METHODS ON Session FOR CREATING A MESSAGE CONSUMER
>>
>> In addition, two new methods on Session would be needed to
>> allow the batch size and timeout when creating a MessageConsumer:
>>
>> MessageConsumer createConsumer(Destination destination,
>> String messageSelector, boolean NoLocal, int maxBatchSize,
>> long batchTimeout)
>>
>> MessageConsumer createDurableConsumer(Topic topic, String
>> name, String messageSelector, boolean noLocal, int
>> maxBatchSize, long batchTimeout)
>>
>> NEW METHODS ON MessagingContext FOR SETTING A MESSAGE LISTENER
>>
>> We would need similar new methods on MessagingContext. You
>> will remember that this currently offers methods to set the
>> message listener directly, five for MessageListener and five
>> for BatchMessageListener, making ten in total.
>>
>> We would drop the latter five, and add two new methods
>> methods (one for queues and non-durable subscriptions and one
>> for durable subscriptions) to allow batch size and timeout to
>> be supplied, making seven in total:
>>
>> setMessageListener(Destination destination, String
>> messageSelector, boolean noLocal, int maxBatchSize, long
>> batchTimeout, MessageListener listener)
>>
>> setMessageListener(Topic topic, String subscriptionName,
>> String messageSelector, boolean noLocal, int maxBatchSize,
>> long batchTimeout, MessageListener listener)
>>
>> NEW METHODS ON MessagingContext FOR CREATING A SYNC MESSAGE
>> CONSUMER
>>
>> If we wanted to extend this feature to synchronous consumers
>> we would also add two new methods for creating a
>> SyncMessageConsumer (one for queues and non-durable
>> subscriptions and one for durable subscriptions):
>>
>> SyncMessageConsumer createSyncConsumer(Destination
>> destination, String messageSelector, boolean noLocal, int
>> maxBatchSize, long batchTimeout)
>>
>> SyncMessageConsumer createSyncDurableConsumer(Topic topic,
>> String name, String messageSelector, boolean noLocal, int
>> maxBatchSize, long batchTimeout)
>>
>> ==================================================================================
>>
>>
>> I hope this is clear! If not, please let me know.
>>
>> Nigel
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2012.0.1913 / Virus Database: 2114/4872 - Release
>> Date: 03/15/12
>>
>>
>>
>>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.1913 / Virus Database: 2114/4873 - Release Date: 03/15/12
>