Sorry Alex, I'm sure you do. I'm learning and trying to understand your
situation.
Although it is reasonable to create a "leased" queue (with an 'x-expires'
argument) for replies to Rpc requests (on the grounds that the clients cannot
be replied upon to drain them), I do not think it reasonable to do this for the
server queues unless you can tolerate requests being (quietly) lost.
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?
Well, I think I can answer my own question -- please confirm if this is right:
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.)
If the server dies there is still the possibility that it did so after pulling
the request from the queue and before posting a reply -- unless the requests are
'transactionally' processed. So it looks like you need the request processing to
be a transaction so that all requests not in the queue (when it expires) have
definitely been processed.
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).
In one of your original posts:
> "I want to keep my "rpc" queue alive even when the RPC server software is
> being upgraded so that users will only see a delay in the responses (and no
> lost requests)"
it looks like you could actually schedule a takeover of the 'offline' server
from the RpcServer, and have complete control of the policy for handling
requests in 'dead' server queues.
A dead-letter mechanism would be convenient in this case, because you would not
then have to 'take-over' any queues and the 'offline' server could be run
permanently, without a need to monitor the servers for failure.
Have I understood now?
Steve Powell (a learning bunny)
----------some more definitions from the SPD----------
avoirdupois (phr.) 'Would you like peas with that?'
distribute (v.) To denigrate an award ceremony.
definite (phr.) 'It's hard of hearing, I think.'
modest (n.) The most mod.
On 5 Dec 2011, at 02:48, Alex Grönholm wrote:
> Dear Steve,
>
> I know how to create queues properly. That was never the issue. The issue was that if I created a leased queue, take the consumer offline and leave it that way and the queue expires, the client is never notified that the message was dropped and it will continue to wait for a response forever. That is not how I want it to work. I expect the server to send some return message when the queue dies. The mandatory flag does not help since it only returns the message if it's not routed to a queue (which it is). But like I said before, the dead lettering feature should help with this.
> _______________________________________________
> rabbitmq-discuss mailing list
>
[hidden email]
>
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Locked
