[rabbitmq-discuss] Limiting the number of non-ack messages cause of subsystem

Sun Oct 23 10:59:25 BST 2011

Hi Matthew,
yeah that's the other way I was thinking about. The problem is, that
there might be different execution times for each thread. So imagine
the following situation:

- 3 Threads runtime 10 seconds
- 4 Threads runtime 25 seconds
- 3 Threats runtime 200 seconds

Discarding the Consumer for the time till all the Threads are finally
executed would result in an waiting time of 200 seconds. With the ACK
approach I could automatically assign an new thread after 10 seconds.
So from your side, that would be proper way? Are there any samples for
it?

Regards Johannes

On Oct 23, 12:42 am, Matthew Sackman <matt... at rabbitmq.com> wrote:
> On Sat, Oct 22, 2011 at 02:08:40PM -0700, jhiemer wrote:
> > I am currently facing the following situation:
> > My setup has a Topic Exchange, wherein all messages are stored. The
> > problem is: the messages consumed are limited by the backend-system.
> > The backend-system is only able to process 10 message at the same
> > time. Each of this messages is bound to a separate thread and I need
> > to wait for its execution until a "slot" is free again. The execution
> > time may vary between 10 seconds and 10 minutes. Is it reasonable to
> > send ACKs just after this amount of time, for acceptance of new
> > messages?
>
> Yes, that will be fine, but you might want to consider some other
> approaches. You could cancel the consumer, then ack all of the msgs. At
> that point you'll receive no further msgs. Then, when you're ready
> again, recreate the consumer and grab the next 10 msgs. This will only
> work effectively if you set basic.qos prefetch count to 10 also.
>
> However, thinking about it, there may not really be much advantage
> between what I'm suggesting and just delaying the acks. Especially if
> you still do the basic.qos prefetch = 10 even in the ack-only version.
>
> Matthew
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss