[rabbitmq-discuss] per-queue message TTLs [was Re: Bound Queues]

[Garrett Smith]

On Wed, Apr 14, 2010 at 1:13 PM, Matthias Radestock
<matthias at rabbitmq.com> wrote:
> Dan Di Spaltro wrote:
>> On Wed, Apr 14, 2010 at 4:13 AM, Tony Garnock-Jones <tonyg at lshift.net> wrote:
>>> if only it were a per *queue* ttl, it'd be so much easier!
>> ttl's on a queue level would be very useful to us
>
> That's a really interesting idea, and it is a lot easier to implement
> than per-message TTLs.
>
> So here is a question to all RabbitMQ users who have been asking /
> secretly wishing for TTLs: Would per-queue TTLs, i.e. all messages
> getting the same TTL when they are enqueued, be good enough (or even
> preferable) for you? Or do you definitely need to be able to specify
> TTLs on per-message basis (and if so, what is the use case)?

Per message ttl and per queue ttl strike me as being very different
and both having valid use cases.

Per message ttl is specified based on the producer's requirement or
vantage point. E.g. a caller might designate a request as being valid
only for a certain amount of time (e.g. request price quote) -- or the
message content is no longer valid after the expiration (e.g. send
price quote). In such cases queues have nothing to say about ttl.

A per queue ttl would apply to consumers. E.g. a consumer might not
fulfill a request because it's become "stale".

For my part, per queue ttls would be preferable. I want my consumers
to be able to drop off, come back and handle requests that aren't
"stale" (basically to handle restarts, though there are other
scenarios). In my case, the consumers know what stale means better
than the producers, though that's obviously application specific.

I see both being reasonable features that are independent of one another.

Garrett