[rabbitmq-discuss] Using rabbitmq-http2 (was: simple.publish over the JSON RPC interface)
n8gray at n8gray.org
Mon Aug 10 22:11:12 BST 2009
On Mon, Aug 10, 2009 at 10:24 AM, Tony Garnock-Jones<tonyg at lshift.net> wrote:
> 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.
Ok, so if you set timeout 1 bigger than timeout 2 you get trouble,
unless there's something else keeping the channel alive.
> 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.
Actually, my publisher use case doesn't require long timeouts -- It's
quite the opposite. I'm trying to use Google App Engine to publish to
a rabbitmq server. It just needs to fire & forget events, one at a
time, as quickly as possible. This is why having simple.publish block
for several seconds was alarming to me.
For my subscriber code, OTOH, I want to have a long-running,
low-maintenance connections so this information will be very useful.
> I will alter the code to make cast() non-long-polling. Thanks for
> drawing this to my attention!
Sounds like a good move.
More information about the rabbitmq-discuss