On 4 September 2014 18:47, Rob Godfrey <[email protected]> wrote:
> > > > On 4 September 2014 18:26, xiaodan.wang <[email protected]> > wrote: > >> Thanks Rob, was afraid that was the case. We built a system with mixed >> asynchronous and synchronous consumers using AMQP 0-10. Most of the time, >> messages are consumed asynchronously. But if we dequeue a "bulk" message, >> we >> create a new session to consume multiple messages synchronously but wrap >> the >> acknowledgement/dequeue in the context of a single transaction. >> Unfortunately, it sounds like delivery and acknowledgement goes >> hand-in-hand >> with AMQP 0-91 so "bulk" consume is no longer possible. >> >> A couple of quick questions from your reply in the other thread (sorry for >> jumping around) >> >> http://qpid.2158936.n2.nabble.com/Re-1-Queue-with-2-Consumers-turn-off-pre-fetching-td6934582i20.html >> >> > 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. >> >> We might start looking into this as a short term solution. Is it easier to >> try on an older client (i.e. v0.16)? >> >> > Let me have a think about this over the weekend, I'm not sure whether the > easier change will be to code up something in 0-10 or 0-9-1 (I'm inclined > to think the latter may actually be simpler... but I'd need to look at it > more carefully). > To expand a little further... The behaviour I'm thinking about for 0-9-1 would be that on a synchronous session, every time you call receive() the client opens up the credit window enough for you to receive a message if there isn't currently credit enough to get the message. At the point a commit occurs (on a transacted session), or an acknowledge (on a client ack session), the window is reduced again such that no new messages will be prefetched until a receive is called... I've not yet looked how "hard" this would be... The other (potentially simpler for me, but hackier) possibility would be to provide some way of allowing you to manually flex the prefetch size on an individual session... this would probably require casting into a qpid specific class for you so you could directly manipulate the session object. I'm maxed out in meetings all of tmr, so I'm not going to have a proper chance to investigate until Saturday.... Cheers, Rob > >> >> > Meanwhile I've also knocked up an implementation of the "single consumer >> > across many queues" idea that I floated the other day. That won't make >> it >> > into 0.30 (it's currently only on my laptop), but I would hope it would >> be >> > in 0.32, or whatever the next release is called. Note that this change >> > will require both a new client and a new broker, but should also be >> easily >> > available from all the other 0-10 clients. >> >> If there is plans to release this in v0.32/trunk, we will be super eager >> to >> test it out :) >> > > > The code is already on trunk, though it's very much "experimental". To > enable the feature on the broker you need to run with > -Dqpid.enableMultiQueueConsumers=true > > To consume from such an address you need to use an address string like > > > ADDR: '' ; {node : { type : queue }, link : { x-subscribe : { arguments : > { x-multiqueue : [ q1, q2, q3 ] } } } } > > where q1, q2 and q3 are the queues you wish to consumer from. > > Note the names of the arguments / system properties are open to change if > I can think of something better... and like I said it's very experimental - > I've not had a chance to do much other than a very basic test that it will > receive messages from any of the given queues. > > Hope this helps, > Rob > >> >> Cheers! Dan >> >> >> >> >> -- >> View this message in context: >> http://qpid.2158936.n2.nabble.com/Synchronous-consumer-can-only-dequeue-1-message-in-AMQP-0-91-tp7613017p7613067.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] >> >> >
