introduce Connection Config class

[bollhals]

Proposed Changes

Introducing a connection config (name to approve) per created connection out of the ConnectionFactory that is independent of the factory itself. Meaning the config is immutable.

Background on this change:
I had a project in which I had to create two connections to two different servers, so I initially reused the connection factory, but it ended up being the wrong decision, as it is often referred to during the lifetime of the connection.

Types of Changes

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)

Checklist

• I have read the CONTRIBUTING.md document
• I have signed the CA (see https://cla.pivotal.io/sign/rabbitmq)
• All tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)
• Any dependent changes have been merged and published in related repositories

Further Comments

I'll update the API once the approach itself is wanted and approved.

[michaelklishin]

I like this idea but we should recognise that this is definitely a major breaking change that would invalidate a lot of tutorials and blog posts out there. I guess it's fine since we roughly do such changes once a decade 😅

[bollhals]

I like this idea but we should recognise that this is definitely a major breaking change that would invalidate a lot of tutorials and blog posts out there. I guess it's fine since we roughly do such changes once a decade 😅

Well it's only the IAuthMechanism that changed and the ConnectionConfig that's new. So I'm not sure how many turtorials would be affected by this.

[michaelklishin]

Yes, most content on the Web would not use ConnectionConfig which would be confusing at first. That'd be the only reason not to adopt this change.

[bollhals]

So should we proceed with this or abandon?

[michaelklishin]

I personally think the gain isn't significant enough.

[bollhals]

One question though, whats the expectation when I change a property on the factory, shall all connextions be picking this change up or not?
(Whatever the expectation is, it should be documented then)

[michaelklishin]

@bollhals all new connections instantiated by that factory should be picking it up.

[bollhals]

@bollhals all new connections instantiated by that factory should be picking it up.

all new means not the old ones?
If so, we'd need a change like this one to do this.

[michaelklishin]

How can or why would already instantiated connections be affected by a factory change? It has already produced them.

[bollhals]

How can or why would already instantiated connections be affected by a factory change? It has already produced them.

E.g. NetworkRecoveryInterval is read once it is used. So it can be changed after the connection was established. Same for TopologyRecovery. Any Property that is accessed inside of the connection/model class is affected.

[lukebakken]

I just rebased this on main and will review more thoroughly soon. The idea of immutable configuration seems good to me.