[rabbitmq-discuss] Dead-Lettering Queue Contents On Queue Expiration
Alex Robson
asrobson at gmail.com
Fri Jan 17 22:08:15 GMT 2014
I have updated the pull request. I jumped the gun a bit in thinking that I
had solved this with the initial pull. I still may not have resolved it in
a way that would make sense to devs who know the code base better than I
do. I wasn't sure if there were a better way to remove bindings from an
expiring queue and its DLX, so I'm removing them first from the destination
using rabbit_binding:remove_for_destination and then calling the exchanges
remove_bindings. The latter call is necessary because with out it, a
consistent hash exchange will retain invalid routes and continue to try and
route messages to the expired queue.
Let me know what you think. If there are things I can do to improve it well
enough for consideration, I am happy to do them. I also don't expect I'd
have any problems signing a CLA if you're interested in the PR. I
understand there could be performance implications if one allows a queue to
grow to a massive number of messages and then expires the queue, however,
as I mention in the PR, I can recreate a similar scenario with DLXs and
message TTLs. I think with this kind of system, there's some caveat emptor
in how one manages things like queue depth. In our scenario, the only real
reason for a queue's depth to get large is when a consumer bites the dust.
Having a short TTL on a queue would actually allow us to expire the queue
quickly to prevent an explosion of messages that suddenly have no consumer
(and may never have again).
If the performance considerations make this too rubbishy for inclusion, let
me know. Willing to help out any way I can but also just as willing to step
back and let the pros handle it.
Thanks,
Alex
On Thu, Jan 16, 2014 at 5:25 AM, Michael Klishin <mklishin at gopivotal.com>wrote:
>
> On 16 Jan 2014, at 14:56, Simon MacMullen <simon at rabbitmq.com> wrote:
>
> > If you want to send us a PR then that's great, but please be aware that
> a) you'd need to sign a contributor agreement and b) it might be harder
> than you think. But c) it might not :-)
>
> FTR:
> https://github.com/rabbitmq/rabbitmq-server/pull/29/files
>
> MK
>
> Software Engineer, Pivotal/RabbitMQ
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140117/fc95f475/attachment.html>
More information about the rabbitmq-discuss
mailing list