Thanks Rajith; The reason for onMessage() is to be able to listen on multiple consumers from a single thread; If you used receive(), you need to have one thread per consumer blocked on receive and in a system that is general purpose messaging framework for multiple consumers with varying traffic load on each consumer, reserving thread capacity is not a good problem to solve.
Thanks Vijay -----Original Message----- From: Rajith Attapattu [mailto:rajit...@gmail.com] Sent: Friday, July 13, 2012 10:58 AM To: users@qpid.apache.org Subject: Re: Batch/Bulk receive messages using java client? Both onMessage() and receive() will fetch messages. By default we prefetch 500 messages at a time (if available on the server). I don't see any advantage of using both receive and ML together, it will only complicate your code. There is no periodic polling, when messages become available the broker will push messages to the client subject to credit availability. Rajith On Fri, Jul 13, 2012 at 12:45 PM, Vijay Devadhar <vdevad...@salesforce.com> wrote: > Hi Gordon, > > Thanks for the suggestion. > > What is the reason for recommendation to not mix onMessage() and > subsequent receive? In theory, this will work well since onMessage() > is like a signal and receive() will actually fetch all the data; This > will avoid the need for periodic polling of data. > > In practice, will we run into efficiency issues or some other mixup in > the transport layer? I am just trying to understand. > > Thanks > Vijay > > -----Original Message----- > From: Gordon Sim [mailto:g...@redhat.com] > Sent: Thursday, July 12, 2012 10:09 AM > To: users@qpid.apache.org > Subject: Re: Batch/Bulk receive messages using java client? > > On 07/12/2012 05:53 PM, Praveen M wrote: >> Hi, >> >> I'm trying to explore if there are ways to batch message processing. >> Batching message processing would help us improve performance for >> some of our use cases, where we could chunk messages and process them >> in a single callback. >> >> Have anyone here explored building a layer to batch messages. >> >> I am using the Java Broker and the Java client. >> >> I would like to stick to the JMS api as much as possible. >> >> This is what I currently have, still wondering if it'd work. >> >> 1) When the onMessage() callback is triggered, create a consumer a >> pull more messages to process from the queue where the message was >> delivered from. >> 2) Pull messages upto the number of my max chunk size, or upto the >> messages available in the queue. >> 3) process all the messages together and commit on the session. >> >> I'd like to hear ideas on how to go about this. > > I wouldn't mix using MessageListener and receive() (and you don't need to > create a consumer per batch). > > Otherwise, using receive() to get N messages (if available), process them all > together and then either manually acknowledge or commit seems quite simple > and sensible to me. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > additional commands, e-mail: users-h...@qpid.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For > additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
