Connection recovery

[vicneanschi]

It would be nice to have a reconnect options.
Looks like there is a Java implementation for that feature https://www.rabbitmq.com/api-guide.html#recovery

[cookie-bytes]

👍

[jamlen]

👍

[jgato]

+1

[ralcini]

+1

[rikaardhosein]

I'm going to have a go at implementing this.

[sreeix]

+1

[squaremo]

@rikaardhosein Bunny (https://github.com/ruby-amqp/bunny) and the RabbitMQ Java client (https://github.com/rabbitmq/rabbitmq-java-client) may be good examples to follow. The latter is based on the former, I believe, but maybe have innovations.

You can read my reservations and fears about auto-recovery in the issue #25. As MK points out there, the model in bunny/rabbitmq-java-client is pretty well proven by now, so perhaps my fears are unfounded.

[michaelklishin]

@squaremo @rikaardhosein the first client to implement automatic connection recovery was amqp gem. Then Bunny, then Java client and .NET. Note that Java client and Bunny have pretty different APIs, so their implementations differ moderately, but the main idea is the same.

Bunny and the Java client are good examples to follow (in fact, replicate).

[michaelklishin]

Overall the ideas in Bunny and Java client have worked well for multiple clients in pretty different languages:

• Ruby (amqp gem, Bunny, March Hare)
• Java
• C#
• Clojure (Langohr, previously with a pure Clojure implementation, now based on the Java client)

[squaremo]

My desiderata:

• auto-recovery is explicitly optional
• user pays -- where there's a cost, you only pay it if you've switched recovery on
• no relying on internal state, please

[michaelklishin]

Recovery is currently opt-in in Java and .NET clients. It is opt-out in Bunny. We haven't heard complaints about either decision but I agree.

What do you mean by not relying on internal state?

[squaremo]

What do you mean by not relying on internal state?

Anything but using the public mechanisms available; e.g., no examining buffers or spoofing channel numbers. I'm not ruling out maintaining bookkeeping state -- it'd be a bit tricky otherwise. And there may be exceptions where it's simply impossible to do something any other way.

[michaelklishin]

Agreed. Only a few bits of extra state should be necessary — messing with buffers or sockets beyond detecting network failures should not.

[rikaardhosein]

My work on this is stalled until Saturday. I'll review these comments in
more detail then. Thanks!

On Wed, Jul 29, 2015 at 6:47 PM, Michael Bridgen [email protected]
wrote:

What do you mean by not relying on internal state?

Anything but using the public mechanisms available; e.g., no examining
buffers or spoofing channel numbers. I'm not ruling out maintaining
bookkeeping state -- it'd be a bit tricky otherwise. And there may be
exceptions where it's simply impossible to do something any other way.

—
Reply to this email directly or view it on GitHub
#163 (comment).

[jwalton]

Ok, I've taken a stab at fixing this whole reconnection problem. Check out https://github.com/benbria/node-amqp-connection-manager and see if it solves your use case. If it doesn't, or if you have suggestions, I'm certainly interested in hearing about it. :)

[cressie176]

Rascal also supports connection recovery. It doesn't do any of the clever write ahead stuff discussed in #25, just simply reconnects, reasserts and resubscribes.

[sokardys]

+1

[EmrysMyrddin]

Is this still a wanted feature ?

It seems lot of other clients handles this. The Java implementation even enables it by default now.

[pigLoveRabbit520]

the feature is very import!!!

[cressie176]

Duplicate of #25