[rabbitmq-discuss] Message timeouts

[Alex Grönholm]

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?  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/20111211/b385ade6/attachment.htm>