<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">(26/07/13 16:49), Tom Anderson wrote:<br>
</div>
<blockquote cite="mid:51F29A82.8040302@timgroup.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Implemented exactly as described there, it yields an infinite loop
for unprocessable messages. You might therefore also want to keep
a count of the number of processing attempts in a header on the
message, and more thoroughly reject messages which reach some
maximum number of attempts. I think you could do the final
rejection by setting a routing key on the message when you reject
it for the last time, and having exchange B be a direct exchange
which routes to either queue B or some final deadletter queue.<br>
<br>
If you want exponential backoff in the retries, then life gets
more complicated (multiple timeout queues, selected between by a
routing key set by the consumer of A?). We are currently
pussyfooting around this issue at my company. I will report back
here if we ever implement a good solution!<br>
</blockquote>
<br>
I've just written some code to do exactly this; limited retries with
exponential backoff. That said, we're kind of cheating in that we
store the retry state in a secondary datastore and buffer messages
in the client. <br>
<br>
So whenever we receive a message, we:<br>
<ul>
<li>When we post each message, we assign it a unique message_id<br>
</li>
<li>Lookup message's due time by it's message_id property in our
datastore</li>
<li>Stash the message in a heap queue</li>
<li>When the message becomes due, remove it from the heap queue
and pass it to the client code.</li>
<li>If the client code succeeds, then we finally ack the message.
Otherwise, we reject the message. <br>
</li>
</ul>
<p>Whilst you can scale this horizontally, you will need enough
buffer space to hold a reasonable proportion of your queue,
although<i> what</i> proportion depends on how much you care about
timeliness. Also, you are effectively implementing a secondary
queue in your application (retaining rabbit for it's reliability
properties), which seems less than ideal. <br>
</p>
<br>
<blockquote cite="mid:51F29A82.8040302@timgroup.com" type="cite"> <br>
tom<br>
<br>
<div class="moz-signature">-- <br>
<p>Tom Anderson | Developer | +44 20 7826 4312 | <a
moz-do-not-send="true" href="http://timgroup.com/">timgroup.com</a></p>
<div style="color:DarkGrey; font-size: small;">
<p>STATEMENT OF CONFIDENTIALITY: The information contained in
this electronic message and any attachments to this message
are intended for the exclusive use of the addressee(s) and
may contain confidential or privileged information. If you
are not the intended recipient, please notify Tom Anderson
at TIM Group at <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:tom.anderson@timgroup.com">tom.anderson@timgroup.com</a>
and destroy all copies of this message and any attachments.</p>
<p>TIM Group is the trading name for YouDevise Limited.
YouDevise Limited is registered in England, No. 3331176.
Registered office: 3 Copthall Avenue, London, EC2R 7BH.</p>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
rabbitmq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a>
<a class="moz-txt-link-freetext" href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a>
</pre>
</blockquote>
<br>
</body>
</html>