[rabbitmq-discuss] Using rabbitmq-http2 (was: simple.publish over the JSON RPC interface)
tonyg at lshift.net
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
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
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!
 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
More information about the rabbitmq-discuss