qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijay Devadhar <vdevad...@salesforce.com>
Subject Re: 1 Queue with 2 Consumers - turn off pre-fetching?
Date Sat, 23 Aug 2014 01:46:57 GMT
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 <rob.j.godfrey@gmail.com>
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 <xiaodan.wang@salesforce.com> 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: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message