Hello Gordon, Sorry for the late answer. >> How soon would you need this? It's a nice to have feature, but is not critical for the moment.
>> It seems like we could also perhaps allow that set to be bounded. and e.g. >> have the fetch() call throw a particular exception if a call is made that >> would exceed the bound. Completely agree. I suppose throwing an exception if particular number of messages are fetched, but not yet acknowledged is a perfect choice. I've raise the JIRA: https://issues.apache.org/jira/browse/QPID-4346 Best Regards, Sergey -----Original Message----- From: Gordon Sim [mailto:[email protected]] Sent: Thursday, September 20, 2012 10:51 PM To: [email protected] Subject: Re: How does the prefetch/receiver capacity really work? On 09/19/2012 04:07 PM, Zhemzhitsky Sergey wrote: >>> Can you elaborate a little on the use cases for that behaviour? > > The usecase is the following: we have a c++ client (messaging api) working as > a forwarder to a proprietary system. > The receiver looks like this: > > Message message; > while(!isStopped()) > { > If(receiver.fetch(message, duration)) > { > proprietarySystemAdapter.send(message) > } > } > > In another thread this proprietary system acknowledges processed messages. > The problem is that some of messages can take rather long time to be > processed and some messages can be processed very fast. What I'd like to > achieve is prevent system overloading with a large amount off messages. Thanks, that makes a lot of sense. >>> There are two questions in my mind. The first is simply how to allow users >>> to specify they want that behaviour in a neat and simple way. The second is >>> more problematic. ... > > Currently the receiver has a number of useful methods, such as > getAvailable() - number of messages in the internal queue, > getUnsettled() - number of acknowledged, but not yet confirmed > messages > > I suppose that if there is a method like getUnacknowledged () - number of > received (by means of Receiver::fetch(...) or Receiver::get(...)), but not > yet acknowledged messages it would be possible to implement such a behavior > (receiving the messages only if there are not more than a predefined number > of unacknowledged ones exist) manually. That might be a quick route to solving your issue. It seems like we could also perhaps allow that set to be bounded. and e.g. have the fetch() call throw a particular exception if a call is made that would exceed the bound. How soon would you need this? I'm a little short of time at present, but if you create a JIRA you can assign it to me for now and I'll get to it as soon as I can. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] _______________________________________________________ The information contained in this message may be privileged and conf idential and protected from disclosure. If you are not the original intended recipient, you are hereby notified that any review, retransmission, dissemination, or other use of, or taking of any action in reliance upon, this information is prohibited. If you have received this communication in error, please notify the sender immediately by replying to this message and delete it from your computer. Thank you for your cooperation. Troika Dialog, Russia. If you need assistance please contact our Contact Center (+7495) 258 0500 or go to www.troika.ru/eng/Contacts/system.wbp --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
