Discussion: recovery events for automatically recovering connections (IAutoRecoveringConnection)

[alexdougie]

Reposting from https://groups.google.com/g/rabbitmq-users/c/k9eHUaptlRg

In the move from v5.0.0 to v6.0.0 of the .NET client, IAutoRecoveringConnection was created to hold connection recovery events in #758. However it isn't possible to get hold of one via the public API, as ConnectionFactory.CreateConnection() returns an IConnection.

Is it worth considering a change to the public API to allow for returning an IAutoRecoveringConnection? I can see two ways to do this:

• Non breaking: create another method ConnectionFactory.CreateAutoRecoveringConnection() which returns an IAutoRecoveringConnection. This would ignore whatever value ConnectionFactory.AutomaticRecoveryEnabled is set to, however this could be confusing to API users.

• Breaking: Remove ConnectionFactory.AutomaticRecoveryEnabled, have ConnectionFactory.CreateConnection() create a Connection and return an IConnection, and add ConnectionFactory.CreateAutoRecoveringConnection() which creates an AutoRecoveringConnection and returns an IAutoRecoveringConnection.

I'm not sure what would be preferred. Of course there may be a better solution that I haven't thought of.

At the moment we can work around this by checking if our IConnection object is actually an IRecoveringConnection, casting it and subscribing to the events, but I think it would be better to provide a proper way of getting an IRecoveringConnection.

[michaelklishin]

This is something that we have considered when automatic connection recovery was introduced in 2013-2014, first in Ruby and Java and then in .NET clients.

We can make IAutoRecoveringConnection to be an IConnection with additional recovery-specific public API bits. How does that sound?

[michaelklishin]

Alternatively, we can add the events to IConnection, and for non-recovering connections, they will simply never fire. I assume it will be more or less obvious to the users.

@lukebakken @danielmarbach @bording @stebet @bollhals WDYT?

[alexdougie]

For me personally either option is fine, so long as we can subscribe to the connection recovery events we're happy :)

[michaelklishin]

I vote for adding the event to IConnection, and making it never fire for non-recovering connections. I think this would match most users' expectations. Famous last words, I know.

[danielmarbach]

To me that would also make most sense because by definition events might or might not fire

[michaelklishin]

Found #515 which led to the extraction of the interface in #758. Looks like there are polar opposite opinions on this. I like @danielmarbach's point that events by definition might or might not fire, so perhaps this makes more sense to fold IAutorecoveringConnection back into IConnection.

[michaelklishin]

Submitted a PR that folds IAutorecoveringConnection back into IConnection. This is a 7.0-only change, of course.

@bording @bollhals WDYT?