Hi Helen, that's interesting (and not the way 0-9 works - it doesn't release the prefetched messages when suspended - so I hadn't actually thought of that :-) ).
In terms of overhead, obviously you're going to be doing more work in terms of re-sending messages over and over again... and the broker will have to keep resetting the consumer "pointers" into the queues as messages are released back into the queue... however I guess the only way to determine if this overhead is significant is for you to test it with your use-case. It would certainly make sense if you could somehow determine when you are processing a long running messages and suspend the session then... if your message processing would be < 1s then I'd wonder if the work of releasing all the messages and then having them resent might not dominate the amount of time actually spent on actual message processing... It certainly sounds like it might be a workaround for you at the moment though. As I said to Dan earlier I'll have a look around the 0-9 codepath to look at implementing a more sensible mechanism for synchronous sessions with low prefetch buffers (because this is actually an issue that I've run into elsewhere). However it does seem like this might be a lower impact solution for you if the overhead is not too significant and/or you can choose to only do this if you determine that you have spent > x seconds processing the message or something. -- Rob On 5 September 2014 21:36, Helen Kwong <[email protected]> wrote: > Hi Rob, > > We're looking into one idea that you suggested, where you said: > > > It may be possible to code a client library side change without changing > > the broker (basically reduce consumer credit to 0 as soon as one consumer > > has a message, and release any messages that have been prefetched), but > > that probably isn't a trivial piece of work. > > I'm looking at the 0.16 client on 0-10 (which is what we've been using), > and while I couldn't find where the consumer credit is kept track of in the > client code (perhaps this is done on the broker), I did find a method > AMQSession_0_10#sendSuspendChannel() that seems like might solve our > problem. What I'm doing right now is call sendSuspendChannel(true) to > suspend the session's message flow whenever a message listener receives a > message in onMessage(), and then at the end of onMessage(), we call > sendSuspendChannel(false) to resume the message flow. The behavior we've > seen is that when we call sendSuspendChannel(true), it releases the > prefetched messages by this session, so that if another session's consumer > would be able to receive the message. > > Do you see any problems with this possible solution? What is the overhead > of suspending and resuming the session each time a listener receives a > message? > > Thanks, > Helen > > > On Fri, Aug 29, 2014 at 5:26 PM, xiaodan.wang <[email protected] > > > wrote: > > > rgodfrey wrote > > > Have you tried the latest trunk revision (or rather any trunk version > > > after > > > http://svn.apache.org/r1621143). I've made some changes that may (or > > may > > > not) help. In particular messages that arrive in 0-9-1 in ADDR mode > will > > > get ADDR addresses and (hopefully) a type appropriate to their nature. > > > > > > I haven't requested inclusion of this change into 0.30 yet... but let > me > > > know if it helps. > > > > Awesome, the latest trunk solved the AMQTopic/Queue issue. > > > > Cheers! Dan > > > > > > > > > > -- > > View this message in context: > > > http://qpid.2158936.n2.nabble.com/Re-1-Queue-with-2-Consumers-turn-off-pre-fetching-tp6934582p7612835.html > > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
