Hi

This question is based on a hypothetical situation that I am going to do my
absolute best to avoid. I fully expect a "don't do that, it's a bad idea"
response. But just for arguments sake, I'd like to know whether such a
scenario is possible with rmq. Forewarned is forearmed, as they say..... :D

The scenario would be a durable persistent queue Q with n consumers C1, C2,
.. Cn. The queue should round-robin messages off to each consumer but only
delivering the next message to the next consumer when the previous consumer
has ACKed or REJECTed the last one. If the previous consumer failed in some
way, then that message should be delivered to the next consumer immediately
instead of delivering the next message in the queue. In this fashion, a
guaranteed order of processing could be relied upon and it would be
fault-tolerant with respect to consumers.

The only possible solution I could think of was setting the qos.prefetch to
a huge number, say 1000000. As I understand it, that will deliver 1000000
messages to one consumer before it starts delivering them to the next.

Any thoughts?

Cheers
Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110713/f825e0af/attachment.htm>

Search Discussions

  • Eugene Kirpichov at Jul 13, 2011 at 10:30 am
    No, IIRC qos doesn't do that. It will still roundrobin, but it will
    not stop roundrobining to a particular consumer until you accumulate
    100000 unacked messages there.

    2011/7/13 Lee Henson <lee.m.henson at gmail.com>:
    Hi
    This question is based on a hypothetical situation that I am going to do my
    absolute best to avoid.?I fully expect a "don't do that, it's a bad idea"
    response. But just for arguments sake, I'd like to know whether such a
    scenario is possible with rmq. Forewarned is forearmed, as they say..... :D
    The scenario would be a durable persistent queue Q with n consumers C1, C2,
    .. Cn. The queue should round-robin messages off to each consumer but only
    delivering the next message to the next consumer when the previous consumer
    has ACKed or REJECTed the last one. If the previous consumer failed in some
    way, then that message should be delivered to the next consumer immediately
    instead of delivering the next message in the queue. In this fashion, a
    guaranteed order of processing could be relied upon and it would be
    fault-tolerant with respect to consumers.
    The only possible solution I could think of was setting the qos.prefetch to
    a huge number, say 1000000. As I understand it, that will deliver 1000000
    messages to one consumer before it starts delivering them to the next.
    Any thoughts?
    Cheers
    Lee


    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


    --
    Eugene Kirpichov
    Principal Engineer, Mirantis Inc. http://www.mirantis.com/
    Editor, http://fprog.ru/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedJul 13, '11 at 9:26a
activeJul 13, '11 at 10:30a
posts2
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Lee Henson: 1 post Eugene Kirpichov: 1 post

People

Translate

site design / logo © 2022 Grokbase