[rabbitmq-discuss] Re try and Throttling

Thu Mar 10 14:28:19 GMT 2011

Thanks for speedy reply!

Too bad about the "delay plugin" thought...:(

So, one last (hopefully) request. 

What are some common patterns around delaying a message then?

One solution I've found on the forum is to put in an "expiry date" on the
message. This simple approach would just have the Producer inspecting the
message before processing, else requeue.

However, the one downfall of this approach results in a lot of needless
"chatter" between the Server and the Producer. Can I process? Can I process?
Can I process? Can I process?, ....

Any other ideas or suggestions?

Much appreciated!

DP

Marek Majkowski wrote:
> 
> On Wed, Mar 9, 2011 at 15:00, butterdave2 <mark.pork at gmail.com> wrote:
>>
>> What about simulating a delay by not republishing a message back (via
>> channel.basicReject) onto the queue by the Consumer code? If I'm not
>> mistaken, as long as the Channel is kept alive, that message can be held
>> out
>> of the queue indefinitely.
> 
> This is correct if you're using acknowledgments.
> 
>> On another note, could a new plugin provide the global delay settings on
>> Rabbit?
> 
> I don't think that's possible.
> 
> 
> 
> 
>> Marek Majkowski wrote:
>>>
>>> On Tue, Mar 8, 2011 at 16:08, butterdave2 <mark.pork at gmail.com> wrote:
>>>>
>>>> Is there anything in Rabbit that can control the amount of times a
>>>> consumer
>>>> may "retry" a message?
>>>
>>> No, but if the message is redelivered you should see "redelivered"
>>> field being set
>>> to "True".
>>>
>>>> There may be instances when a message has something about it that will
>>>> cause
>>>> it to "fail" downstream in the Consumer code. I wouldn't want to
>>>> continue
>>>> to
>>>> hammer away...
>>>
>>> Correct. But rabbit can't know if your consumer died due to the message
>>> or due to something else, power failure or something.
>>>
>>> It's the programmers responsibility to handle dying-consumer case.
>>>
>>>> I can programmatically include the number of retry attempts with the
>>>> message
>>>> (a kind of metadata) and then design the Consumer to query this field.
>>>> (then
>>>> once we hit our MAX_RETRY, we will do something else to it...)
>>>
>>> Sounds good.
>>>
>>>> Also in similar fashion, is there any control around "throttling" or
>>>> slowing
>>>> down the consumption of messages from a queue?
>>>
>>> You can't control that, Rabbit is designed to deliver messages when it
>>> can.
>>> But you can use basic.qos to do something similar. Or, if you're
>>> desperate
>>> you may just run basic.get with regular intervals.
>>>
>>> Cheers,
>>>   Marek
>>> _______________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq-discuss at lists.rabbitmq.com
>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Retry-and-Throttling-tp31098579p31107114.html
>> Sent from the RabbitMQ mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> 
> 

-- 
View this message in context: http://old.nabble.com/Retry-and-Throttling-tp31098579p31116158.html
Sent from the RabbitMQ mailing list archive at Nabble.com.