[rabbitmq-discuss] RPC Client side timeout

[Tony Garnock-Jones]

Hi Ben,

Ben Hood wrote:
> When you send the top half you can specify an expiration property, but  
> I can't see how this gets processed on the server side (from looking  
> at the processing code). Furthermore this is a string value and I  
> haven't seen an example of it or an explanation in the spec.

It isn't processed at all in the server at the moment, precisely because
the spec doesn't define it properly. A future release of the spec will
fix the problem.

> On the client, one easy to way to do this would be just to add a get()  
> method on the blocking cell that passes in a timeout value, but I'm  
> not sure what should happen once it times out. Should the consume be  
> cancelled or should an appropriate property be set during the  
> initialization of the consume that indicates to the server that it  
> should clean unattended queues up after a while?

I'd suggest supplying, at RPC tophalf time, a default reply value as
well as the timeout, and then starting a timer task that, when it
expires, uses setIfUnset(defaultReplyValue) to release the RPC caller.
Also, the current use of set(receivedValue) in the consumer should be
replaced by setIfUnset(receivedValue).

At the moment, RpcClient itself doesn't queueDelete. Maybe it should
have the option of doing so, at the application's discretion. Then the
application can use the defaultReplyValue to decide what to do, and can
choose to delete the RpcClient and possibly the RpcClient's queue, at
its option.

Regards,
  Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ | Email: tonyg at lshift.net