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

Mon Aug 10 18:24:29 BST 2009

Nathan Gray wrote:
> "simple.publish" block until the session times out.  This seems very
> odd to me.  Is there some rationale for this design that I'm not
> understanding?

There are *two* timeouts involved:

 1. the "session" timeout. This is the length of time that an open
    channel object will survive in the absence of any active poll()
    calls. It's also used to compute the length of time to wait for
    incoming work before replying to active polls.

 2. a per-method-call timeout on JSON-RPC objects (including those
    implementing the AMQP channel API). This is a normal RPC timeout
    and defaults to five seconds.

With regard to (1), the idea is that because AMQP can involve
asynchronous events, there will usually be a long-polling call
outstanding -- either a cast() or a poll(). Previously this has been
fine, but I suspect now that cast() *shouldn't* also act as a long-poll.
The session timeout is set at channel creation time. If a channel is
left alone for longer than the session timeout, it closes itself.

With regard to (2), this is controllable on a per-request basis with and
"x-json-rpc-timeout" header that can take values of "default" (5s,
currently), "infinity", or a whole number of milliseconds.

So, for your specific use case:

 1. run a long-polling poll() call in the background to keep the
    channel alive.

 2. set the session timeout (argument to "open") to a bigger
    number of seconds.

 3. set each individual request timeout to longer than 5000ms by
    using the "x-json-rpc-timeout" header.

I will alter the code to make cast() non-long-polling. Thanks for
drawing this to my attention!

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