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

[Nathan Gray]

Hi Tony,

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
>> 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.

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.

Cheers,
-n8

-- 
http://n8gray.org