Hi Vijay, It is certainly possible to make the client/broker use 0-9-1 and you would then end up getting per-session prefetch, however as the 0-8/0-9/0-9-1 and 0-10 paths in the client are fairly distinct in various areas you would also see a number of other differing behaviours, which is the main reason they are documented separately. It would depend on how you are using the client exactly differently they might behave.
You can instruct the client what protocol version to attempt initially (it defaults to 0-10), by setting the JVM system property qpid.amqp.version, e.g to "0-9-1". Alternatively, you can instruct the broker not to support 0-10 on some or all of its AMQP ports such that the java client will negotiate down to the lower supported protocol version after the initial attempt at 0-10 is rejected. How to do this varies depending on the broker version, but is fairly easy on recent versions via the port settings in the web management. Robbie On 23 August 2014 02:46, Vijay Devadhar <[email protected]> wrote: > Thanks Rob. Is it feasible for us to configure the client-broker to work > in AMQP 0-8/0-9/0-9-1 mode? If yes, do we end up getting the session level > prefetch limit? > > > On Fri, Aug 22, 2014 at 4:37 PM, Rob Godfrey <[email protected]> > wrote: > > > Hi Dan, > > > > The document you refer to is discussing the behaviour of the client when > > speaking AMQP 0-8/0-9/0-9-1 - these versions of AMQP allow for setting of > > credit (prefetch) at a session wide level, but not on a per consumer > basis. > > > > I believe you are using the client and broker in AMQP 0-10 mode. In AMQP > > 0-10 credit is issued on a per consumer (rather than per session) > basis. I > > don't believe there is a way of setting a session wide credit limit in > the > > AMQP 0-10 protocol. > > > > > > -- Rob > > > > > > On 23 August 2014 00:41, xiaodan.wang <[email protected]> > wrote: > > > > > Hi Robbie, sorry to resurrect an old thread :) > > > > > > We are seeing an interesting behavior on the Qpid Java client with > > respect > > > to prefetching of messages (maxprefetch). Based on documentation from > the > > > following link, we believe that the prefetch buffer is defined on a per > > > session basis. However, after running a few benchmarks, the prefetch > > buffer > > > seems to be allocated on a per consumer (or per destination queue, not > > sure > > > which one) basis. Namely, when we setup multiple consumers using the > same > > > session, each consumer is buffering separately. Is this the expected > > > behavior? If so, can you suggest a workaround to either turn off client > > > side > > > prefetching or have prefetch buffers scoped at the session level. > > > > > > > > > > > > https://qpid.apache.org/releases/qpid-0.26/jms-client-0-8/book/JMS-Client-0-8-Client-Understanding-Session.html > > > > > > We configured Qpid with asynchronous onMessage delivery with transacted > > > session. Prefetch count on the client is set to 1 (setting prefetch to > 0 > > > did > > > not solve our issue). The experiment involves 2 sessions (A and B) and > 2 > > > destination queues (Q1 and Q2). Each session creates 2 consumers that > > > listen > > > on Q1 and Q2 respectively. Next, we enqueue 2 messages, one long > running > > > message on Q1 and a short running message on Q2. A consumer on session > A > > > pulls the long running message from Q1 and starts working on it. In the > > > meantime, session B does nothing even though there is an unconsumed > > message > > > on Q2. Once session A finishes the long running messages, it consumes > the > > > message from Q2. > > > > > > This seems to contradict our expectation. So we suspected that the > > prefetch > > > buffer is allocated for each consumer on a session (i.e. for session A, > > > with > > > prefetch of 1, it will buffer 1 message from Q1 and 1 for Q2 for a > total > > of > > > 2 messages). To test this theory, we modified the above experiment to > > use a > > > single destination queue (Q1) and consumer for sessions A and B. We > > > enqueued > > > both long running and short running messages in Q1 and did not observe > > any > > > instance in which a consumer was doing nothing while an unconsumed > > message > > > was sitting on the queue. (We repeated this several times with many > > > messages). > > > > > > This seems to indicate that there is a separate prefetch buffer for > each > > > consumer within the same session. Thanks in advance for any help > > > interpreting this behavior! > > > > > > Cheers! Dan > > > > > > > > > > > > -- > > > View this message in context: > > > > > > http://qpid.2158936.n2.nabble.com/Re-1-Queue-with-2-Consumers-turn-off-pre-fetching-tp6934582p7612403.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] > > > > > > > > >
