[rabbitmq-discuss] rabbitmq_jsonrpc_channel reconnect ability?

[Tony Garnock-Jones]

On 11 June 2012 09:55, Marek Majkowski <majek04 at gmail.com> wrote:

> I'm afraid there is no "proper" way. When it works - great. But on
> network errors, I'd assume the state of the channel is undefined.
> I would be surprised if there is a sane way to recover. Best solution
> IMO is to kill the channel and establish a new one.
>

I don't think it's actually so bad in principle, though the implementation
isn't there yet.

The channel object on the server side has a timeout - if there's a waiting
longpoll, the timer isn't counting down, but during periods when the object
is untouched the timer is ticking. The timer is reset to its starting value
whenever the object receives a method call. Eventually, if left alone, the
channel's timer expires and the channel is closed.

So, if you can arrange for the JS to just attempt reconnection over and
over up to the point where the timer must have expired, you can rejoin your
channel state. (It works this way because of the spotty nature of XHR
"connections" in the best case.) You can control the expiry timer length on
the channel object - pass the channelTimeout option (in *seconds*) to the
RabbitMQ.Channel constructor from rabbitmq.js.

If the channel timer has expired, and you try to touch the old channel
object, you'll get an error from the server (because the server doesn't
know what object you mean anymore). In that case, yes, all the channel
state is gone and you need to take extra steps like creating a fresh
channel to work with.

I'm not certain, but it might be the case that a few small (but
carefully-thought-out) changes to rabbitmq.js could make it sanely and
transparently attempt reconnection.

Tony
-- 
Tony Garnock-Jones
tonygarnockjones at gmail.com
http://homepages.kcbbs.gen.nz/tonyg/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120611/24a026f9/attachment.htm>