[rabbitmq-discuss] Message timeouts
Alex Grönholm
alex.gronholm at nextday.fi
Thu Apr 26 06:08:57 BST 2012
11.12.2011 14:14, Alex Grönholm kirjoitti:
> Sorry for taking this long to respond. I've been otherwise engaged and
> forgot about this conversation.
> Thank you for your replies.
>
> If you don't want the server queue requests to be 'lost' then
> don't allow the
> queues to expire!
>
> On the other hand your clients apparently wait forever. Is there
> a reason I
> don't understand why the server queues expire but the clients
> don't have a
> timeout for the responses?
>
> If the upgrade of the server software fails and the developers do
> nothing, the queue expires eventually so that stale requests are
> dropped and the clients will start getting proper error messages
> informing them of this condition.
> This is not the ideal solution of course (per-message TTL and return
> notification would be).
>
> You want requests to either be processed or (reliably) not
> processed. You
> never want the clients to be in any doubt about whether the
> request was
> processed or not. So you wait forever in the client. However,
> requests that
> get discarded never return so the client doesn't know. So you
> want expiry to
> trigger replies to the clients. (Per-queue message TTLs also
> don't return.)
>
>
> Sounds about right.
>
> Let's see -- how would we do this without a dead-letter mechanism?
>
Now that the dead-letter mechanism is part of the server, I don't still
don't see how this could be done. The dead lettered RPC commands would
still have to be processed somewhere.
>
> Well, apart
> from making the server transactional, it might be useful to have
> an 'offline'
> server that can take over any server's queue when it fails and
> either deal with
> the requests [by issuing an 'offline' response?] or arrange for
> the server to
> be restarted (and/or upgraded).
>
>
> This seems fairly complicated. I'll have to look into transactions to
> see if they will help in my case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120426/00ec443b/attachment.htm>
More information about the rabbitmq-discuss
mailing list