Agreed that dead letter queues are a big deal. Which is why expiration on messages doesn't do me much good right now, unless I am missing something. I can't have a message expire and just disappear, I need to be able to respond to it.<div>
<br clear="all">Justin Etheredge<br>Company: <a href="http://www.ecstaticlabs.com" target="_blank">http://www.ecstaticlabs.com</a><div>Blog: <a href="http://www.codethinked.com" target="_blank">http://www.codethinked.com</a></div>
<div>Twitter: @JustinEtheredge</div><br>
<br><br><div class="gmail_quote">On Tue, Dec 7, 2010 at 7:47 PM, Jason J. W. Williams <span dir="ltr"><<a href="mailto:jasonjwwilliams@gmail.com">jasonjwwilliams@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
With basic.reject now being implemented, I'd definitely like to see<br>
"dead letter" queues get a priority. Agree they fit well the TTLs.<br>
<font color="#888888"><br>
-J<br>
</font><div><div></div><div class="h5"><br>
On Tue, Dec 7, 2010 at 4:40 PM, Matthias Radestock<br>
<<a href="mailto:matthias@rabbitmq.com">matthias@rabbitmq.com</a>> wrote:<br>
> Jason J. W. Williams wrote:<br>
>><br>
>> I'd like to see the new queue TTLs extended to handle this...specify a<br>
>> message's lifetime by redeliver count instead of/in addition to age. I<br>
>> think the redeliver count would still be useful information for a<br>
>> consumer to know, but it seems to me the broker should be handling the<br>
>> mechanics of expiration.<br>
><br>
> Before we add yet more ways for messages to disappear from a queue, we want<br>
> to introduce a means by which they can disappear to somewhere other than the<br>
> ether. i.e. dead-letter exchanges. Which we will probably implement at some<br>
> point.<br>
><br>
> Regards,<br>
><br>
> Matthias.<br>
><br>
</div></div></blockquote></div><br></div>