[rabbitmq-discuss] redelivered count

[Justin Etheredge]

Exactly. So we have messages which are about performing a particular action.
If the action is malformed, then it would just keep failing and retrying
forever. But there are valid instances where the message could fail, and it
is because of a temporary issue. Like a web service being down or something.
However, if a message is failing due to something bad in it, we can't just
have it disappear into the ether, we need to know what the issue is and fix
it.

Justin

On Tue, Dec 7, 2010 at 9:05 PM, Jason J. W. Williams <
jasonjwwilliams at gmail.com> wrote:

> Hey John,
>
> I think the intent is to keep a message that's crashing a consumer
> from being endlessly retried.
>
> -J
>
> On Tue, Dec 7, 2010 at 6:15 PM, John DeTreville <jdetreville at vmware.com>
> wrote:
> > I'm a little confused. Would messages be reordered? Is the idea to move
> from message queues to something else?
> >
> > Cheers,
> > John
> >
> > On Dec 7, 2010, at 2:39 PM, Justin Etheredge wrote:
> >
> >> It would interesting and useful if there was some way to see a
> redelivered count on a message. And as a little icing on the cake, it would
> be useful to be able to specify how long before a message is redelivered.
> That way if I specify that a message can be redelivered at most 10 times, it
> won't happen in a thousandth of a second. Any thoughts on this?
> > _______________________________________________
> > rabbitmq-discuss mailing list
> > rabbitmq-discuss at lists.rabbitmq.com
> > https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20101208/931f5c08/attachment.htm>