We are having some pretty major problems with this, so any advice you can give would be appreciated. We have an extremely diverse group of 450+ types of messages. They range from a few ms processing time to several hours and we isolate them by queue. With this setup, we are hitting problems where a high throughput message gets "stuck" behind a long running message. This can give us spike of hours on our dequeue latency where the only good reason for it is the caching of the server.... We asked a pretty specific question, but any thoughts on how we could work around the larger issue would be very much appreciated!
John On Sat, Aug 23, 2014 at 3:36 AM, Rob Godfrey <[email protected]> wrote: > For information, if you use a mixture of clients using AMQP 0-8/0-9/0-9-1 > (which are all substantially the same protocol) and AMQP 0-10 (which is a a > bit different) then the Java Broker should be able to translate > automatically between them allowing messages sent from one protocol to be > received by the other. As long as you are using standard JMS any such > translation should be pretty much invisible. If you are doing non-JMS > things like sending Lists as values in the application headers then you may > run into issues. The AMQP 0-9(-1) <-> AMQP 0-10 conversion in the 0.30 > version of the broker has been improved and should deal with this case and > a few others. > > As you've discovered the 0-8/9/9-1 codepath doesn't currently support the > "ADDR" addressing syntax... Unfortunately the current implementation of > that is somewhat mixed in with 0-10 specific features. > > -- Rob > > > On 23 August 2014 09:09, xiaodan.wang <[email protected]> wrote: > > > Thanks Robbie & Rob! Was able to use your suggestion to force the client > to > > use AMQP 0-9, will re-run our tests to validate session-wide prefetching. > > > > @Vijay, unfortunately ran into "The new addressing based sytanx is not > > supported for AMQP 0-8/0-9 versions" exception when trying to create a > > consumer using AMQP 0-9. Will get it sorted out tomorrow :) > > > > > > > > -- > > View this message in context: > > > http://qpid.2158936.n2.nabble.com/Re-1-Queue-with-2-Consumers-turn-off-pre-fetching-tp6934582p7612411.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] > > > > >
