activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: prefetch and auto acknowledge
Date Wed, 21 Oct 2015 03:53:55 GMT
As Tim said, yes prefetch size definitely has an effect for auto-ack, but
only when messages aren't instantaneously consumed.  If there's a backlog
or messages to be consumed (either because the consumer just connected or
because the producers are slower than the consumers), having a smaller
prefetch buffer will mean that the broker passes over a slow consumer
sooner and that the message load can be more efficiently balanced.  But if
there's no backlog and messages are consumed as soon as they are produced,
there's no effect.
On Oct 20, 2015 6:06 PM, "Timothy Bish" <tabish121@gmail.com> wrote:

> On 10/20/2015 06:51 PM, rth wrote:
> > If I set a prefetch limit will it have any effect if my consumer is using
> > auto-acknowledge? I'm guessing the answer is no. It seems to me the
> message
> > would be sent to the consumer and auto-acknowledged, so the broker would
> > keep sending messages. Is that correct?
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://activemq.2283324.n4.nabble.com/prefetch-and-auto-acknowledge-tp4703212.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
> The messages are acknowledged by the consumer once you consume them, not
> before.  So either you consume them via a receive call which means the
> message is ack'd prior to the return of the receive method, or you set
> an async MessageListener and each message is ack'd before it is passed
> onto the onMessage call.  If you don't do these things then the message
> sits in the prefetch buffer until the consumer is closed, not being
> ack'd and not being dispatched to some other consumer.
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.bish@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

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