[rabbitmq-discuss] Using rabbitmq-http2 (was: simple.publish over the JSON RPC interface)

[Tony Garnock-Jones]

Nathan Gray wrote:
>>  1. the "session" timeout.
>>  2. a per-method-call timeout
> Ok, so if you set timeout 1 bigger than timeout 2 you get trouble,
> unless there's something else keeping the channel alive.

Hmm. There are two kinds of trouble:

 - the session closing when you want it kept open

 - individual blocking operations timing out, perhaps because the
   server is slow, or whatever other reason

To avoid the session closing, you have to poke it every
sessionTimeout-minus-epsilon. To avoid individual blocking operation
timeouts, you have to either make the server not take forever or set the
x-json-rpc-timeout longer.

Where they interact is in the case of the long-poll. The AMQP channel
object is set to deliberately not answer poll() requests until
sessionTimeout/2 has elapsed -- giving long-polling behaviour -- so in
the case of the poll() method, you want the x-json-rpc-timeout header to
let the operation take *at least* as long as sessionTimeout/2.

I did it that way because it's nice and simple, has fairly predictable
behaviour, and generally seemed like a reasonable first approach. Is
there a better way of doing it?

So in summary:

 - poll()'s request timeout needs to be sessionTimeout/2 + epsilon

 - blocking operation timeouts should be under user control but
   some reasonable default should exist

 - sessionTimeout should be under user control, but values less than
   about a minute are probably not a good idea, especially once the
   number of connections goes up? We haven't good data here.

... and of course I still need to make the changes we discussed
yesterday :-)

Cheers,
  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